home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / relnotes / performer_eoe / ch5.z / ch5
Encoding:
Text File  |  2002-10-08  |  180.3 KB  |  4,489 lines
  1.  
  2.  
  3.  
  4.                                   - 1 -
  5.  
  6.  
  7.  
  8.        6.  _C_h_a_n_g_e_s__f_r_o_m__P_r_e_v_i_o_u_s__R_e_l_e_a_s_e_s
  9.  
  10.        This Chapter identifies incremental changes and enhancements
  11.        since IRIS Performer 2.0.  Changes are presented in reverse
  12.        chronological order, with the most recent releases listed
  13.        first.
  14.  
  15.  
  16.        6.1  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._5_._3
  17.  
  18.        6.1.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._5_._3
  19.  
  20.           +o The geometry under a pfRotorWash node could be
  21.             processed into an OpenGL display list. The rotor wash
  22.             effect would then animate incorrectly (no SCR number).
  23.  
  24.  
  25.        6.2  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._5_._2
  26.  
  27.        6.2.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._5_._2
  28.  
  29.           +o Updated /sample/apps/C++/clipdemo/clipdemo.C so that it
  30.             expects a return of PFQFTR_TRUE on systems without
  31.             support for hardware cliptextures.
  32.  
  33.           +o When PFIBR_NEAREST flags was set in a pfIBRtexture the
  34.             view selected was not always the nearest one (SCR
  35.             857940).
  36.  
  37.           +o The intersection functions pfScene::isect and
  38.             pfNode::isect either crash or return incorrect results
  39.             on scene graphs deeper than 32 levels.
  40.  
  41.           +o The user callback function is called on buttonRelease
  42.             even if only requested for buttonPress in function
  43.             pfuCollectXEventStream.
  44.  
  45.  
  46.        6.3  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._5_._1
  47.  
  48.        6.3.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._5_._1
  49.  
  50.           +o Cliptexture emulation is activated any time a
  51.             cliptexture is loaded on a system without hardware
  52.             cliptexture support.  This is a change from previous
  53.             behavior.  In cases where the previous behavior is
  54.             desired, cliptexture emulation can be disabled by
  55.             setting the environment variable PF_DISABLE_CTE to 1.
  56.             (no SCR number)
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                                   - 2 -
  71.  
  72.  
  73.  
  74.           +o pfQueue sorting had been disabled on platforms which
  75.             use cliptexture emulation.  The new behavior is as
  76.             follows:  On IRIX systems, pfQueues used for
  77.             cliptextures are now sorted by default.  On Linux
  78.             systems, pfQueues used for cliptexture are not sorted
  79.             by default.  In cases where the previous behavior is
  80.             desired, the environment variable
  81.             PFCT_FORCE_QUEUE_SORT_MODE can be set to 1 or 0 to
  82.             force pfQueues used for cliptexture to be sorted or
  83.             unsorted.
  84.  
  85.           +o Cliptexture emulation required that calls to pfTexImage
  86.             and pfTexFormat when setting up a cliptexture be made
  87.             in a particular order, and before the cliptexture was
  88.             created.  This has been fixed (no SCR number).
  89.  
  90.           +o The header_offset token in a cliptexture configuration
  91.             file was not being processed correctly by
  92.             pfdLoadImageCacheAuto().  This has been fixed (SCR
  93.             838936).  In case the previous behavior is desired, the
  94.             environment variable
  95.             PF_CLIPTEX_DONT_USE_CT_HEADEROFFSET_FOR_ICACHES may be
  96.             set by the user.
  97.  
  98.           +o The colors in certain models imported by the FLT loader
  99.             were being corrupted, due to a missing endian flip.
  100.             This has been fixed (mod 111859a).
  101.  
  102.           +o pfDCS::setCoord() was not functioning properly due to
  103.             the 'dirty' flags being mis-set.  This has been fixed
  104.             (SCR 841768).  The fix has also been ported back to
  105.             versions 2.2.15 and 2.4.4.
  106.  
  107.           +o pfGetTime() was reporting negative values on Linux
  108.             systems with CPU clock speeds greater than 2Ghz.  This
  109.             has been fixed (SCR 850864).
  110.  
  111.           +o There are now a set of Performer-Linux rpms/tgz's built
  112.             with gcc-3.0.2 in addition to the rpms/tgz's we usually
  113.             ship that are built with gcc-2.91.  These rpms/tgz's
  114.             built with gcc-3.0.2 solve a number of compilation
  115.             problems with Performer such as having to compile C++
  116.             programs optimized and problems with exception handling
  117.             in Performer programs.
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.                                   - 3 -
  137.  
  138.  
  139.  
  140.        6.4  _N_e_w__F_e_a_t_u_r_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._5
  141.  
  142.  
  143.        OpenGL Performer 2.5 introduces many new features to the
  144.        toolkit, with special attention to six categories of
  145.        enhancements:  Enhanced Realism for the High-End,
  146.        Distributed Rendering, Combinatorial Visual Effects, Ease-
  147.        of-Use, Supporting Huge Datasets, and Commodity Platforms.
  148.        Specific new features are described in the following
  149.        sections:
  150.  
  151.  
  152.        6.4.1  _I_m_a_g_e_-_B_a_s_e_d__R_e_n_d_e_r_i_n_g
  153.  
  154.        Image-Based Rendering enables rendering complex objects,
  155.        such as trees, in real-time with a very low polygon count. A
  156.        complex object is represented by a set of images taken from
  157.        many directions around it. When rendering the object several
  158.        closest views are blended together for each view direction.
  159.        The object is represented by a pfIBRnode, a sub-class of
  160.        pfBillboard.  The views are precomputed and stored in a
  161.        pfIBRtexture as a set of textures. A pfIBRtexture can
  162.        represent a ring of views perpendicular to vertical axis or
  163.        rings of views from all around the object. During rendering,
  164.        the closest textures are selected based on the direction
  165.        from which the object is viewed and mapped on the pfGeoSets
  166.        of the pfIBRnode.
  167.  
  168.        Man pages to see: pfIBRnode, pfIBRtexture, rpc
  169.  
  170.        Sample programs to check out:
  171.                /usr/share/Performer/src/pguide/libpf/C++/IBRnode.C
  172.  
  173.        Utilities to use:
  174.                /usr/share/Performer/src/conv/makeIBRimages.C
  175.  
  176.        Loaders that support Image-Based Rendering: pfb, rpc
  177.  
  178.        Data files:
  179.                /usr/share/Performer/data/ibr/tree/tree.pfb
  180.                /usr/share/Performer/data/ibr/rpc/*.rpc
  181.  
  182.  
  183.        6.4.2  _I_n_t_e_g_r_a_t_i_o_n__w_i_t_h__t_h_e__A_r_c_h_V_i_s_i_o_n__R_P_C__f_i_l_e__l_o_a_d_e_r
  184.  
  185.        OpenGL Performer 2.5 adds a new file loader, shipped for
  186.        both IRIX and Linux, enabling users to read the RPC format
  187.        created by ArchVision.
  188.  
  189.        An ArchVision RPC file contains a set of images that
  190.        represent views of an object from different directions.
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                                   - 4 -
  203.  
  204.  
  205.  
  206.        These images are loaded into a pfIBRtexture. The
  207.        pfIBRtexture is assigned to a pfIBRnode that represents the
  208.        object. During rendering images from the viewes that are
  209.        closest to the current view direction are blended together.
  210.  
  211.        Man pages to see:  rpc, pfIBRnode, pfIBRtexture,
  212.        makeIBRimages
  213.  
  214.        Data files:
  215.                /usr/share/Performer/data/ibr/rpc/*.rpc
  216.  
  217.  
  218.  
  219.        6.4.3  _R_e_a_l_-_T_i_m_e__S_h_a_d_o_w_s
  220.  
  221.        Real-Time Shadows can be cast by selected objects (nodes on
  222.        the scene graph).  For each combination of a specified
  223.        shadow caster and a light source a shadow is projected onto
  224.        each pfGeoSet under the shadow caster.  To speed-up
  225.        rendering, each shadow caster maintains set of pre-computed
  226.        shadows from different directions. For an arbitrary
  227.        direction the closest shadow is selected or two closest
  228.        shadows are blended together.  The precomputed shadows are
  229.        warped to better approximate the correct shadow from any
  230.        random direction (different from the direction that this
  231.        precomputed shadow was generated). At the extreme case, only
  232.        one precomputed shadow can be used - reducing the texture
  233.        memory requirements.
  234.  
  235.        Man pages to see: pfShadow
  236.  
  237.        Sample programs to check out:
  238.                /usr/share/Performer/src/pguide/libpf/C++/shadowsNew.C
  239.  
  240.  
  241.        6.4.4  _L_i_g_h_t__S_h_a_f_t_s
  242.  
  243.        A Light Shaft is a volumetric effect simulated using
  244.        pfVolFog.  A light shaft is defined by its boundary (usually
  245.        cone shaped) and a range of colors and decreasing densities
  246.        along the main axis of the shaft.  Objects inside a light
  247.        shafts are lit. The intensity of light reaching them depends
  248.        on their distance from the light.  A light shaft is rendered
  249.        using a multi-pass algorithm in which each frame the scene
  250.        or its parts are drawn several times .
  251.  
  252.        Man pages to see: pfVolFog
  253.  
  254.        Sample programs to check out:
  255.                /usr/share/Performer/src/sample/C++/volfog
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.                                   - 5 -
  269.  
  270.  
  271.  
  272.        6.4.5  _C_u_l_l__P_r_o_g_r_a_m_s
  273.  
  274.        A Cull Program is a sequence of instructions that is
  275.        executed for each pfGeoSet during the cull traversal.  The
  276.        instructions operate on a set of polytopes. Based on
  277.        intersection tests with these polytops each pfGeoSet can be
  278.        assigned to a specific bin.  The best use of cull programs
  279.        is in multi-pass rendering. If in some passes only parts of
  280.        the scene have to be rendered these parts can be enclosed in
  281.        polytopes and a cull program assigns the relevant pfGeoSets
  282.        into a predefined bin. Drawing just this bin can be much
  283.        faster than drawing the whole scene.
  284.  
  285.        Man pages to see: pfCullProgram, pfChannel
  286.  
  287.        Sample programs to check out:
  288.                /usr/share/Performer/src/pguide/libpf/C++/cullPgmSimple.C
  289.                /usr/share/Performer/src/pguide/libpf/C++/cullPgmMultipass.C
  290.  
  291.  
  292.        6.4.6  _p_f_G_e_o_S_e_t__C_a_l_l_b_a_c_k_s
  293.  
  294.        OpenGL Performer version 2.5 Introduces pfGeoSetCB: a new
  295.        pfGeoSet type, recommended for advanced users only.  A
  296.        pfGeoSetCB lets an application control its drawing.  As with
  297.        traditional pfGeoSets, OpenGL Performer sorts pfGeoSetCB's
  298.        by their pfGeoState. However, instead of drawing themselves,
  299.        pfGeoSetCB's call a user callback for drawing.
  300.  
  301.        Unlike DRAW callbacks, Performer makes no attempt to restore
  302.        graphic state after the callback returns.  This user-
  303.        callback is free to make any OpenGL calls as long as it un-
  304.        does all the graphic state that it modifies.  The obvious
  305.        advantage is speed.
  306.  
  307.        Man pages to see: pfGeoSetCB
  308.  
  309.        Sample programs to check out:
  310.            /usr/share/Performer/src/pguide/libpf/C++/gsetCB.C
  311.  
  312.  
  313.        6.4.7  _p_f_S_h_a_d_e_r__E_n_h_a_n_c_e_m_e_n_t_s
  314.  
  315.        6.4.7.1  _D_y_n_a_m_i_c__P_a_r_a_m_e_t_e_r_i_z_e_d__S_h_a_d_e_r_s
  316.  
  317.        OpenGL Performer 2.4 introduced the notion of shaders, but
  318.        they were limited in that they could not change from frame
  319.        to frame and they were hard coded for each piece of
  320.        geometry, so it was impossible, for instance, to render each
  321.        shaded pfGeoSet normally and then render another pass on top
  322.        of the normal, unshaded pfGeoSet appearance. To get around
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.                                   - 6 -
  335.  
  336.  
  337.  
  338.        these limitations, OpenGL Performer 2.5 introduces several
  339.        shader extensions.
  340.  
  341.        To make shaders dynamic, OpenGL Performer 2.5 introduces new
  342.        classes which multi-buffer pfGeoState and pfFBState so that
  343.        changes to these state elements could be made frame
  344.        synchronously within the shader framework.  These new
  345.        classes are pfFluxedGeoState and pfFluxedFBState. Each of
  346.        these new classes shares the api of its corresponding
  347.        unbuffered class, so using them is simple. To make use of
  348.        these new multi-buffered state elements, pfShader now
  349.        supports dynamic variants of all its pass types. For
  350.        example, there is a PF_SHADERPASS_GEOMETRY and a
  351.        PF_SHADERPASS_GEOMETRY_DYNAMIC. The dynamic pass can take
  352.        the same attributes as the static pass as well as
  353.        pfFluxedGeoState instead of a pfGeoState and a
  354.        pfFluxedFBState instead of a pfFBState. Dynamic passes can
  355.        also take a pfFlux for any of their remaining attributes
  356.        instead of a pointer to the attribute itself.  The reason
  357.        that there is a dynamic/static distinction is for efficency;
  358.        a static pass avoids testing its attributes to see if they
  359.        are dynamic.
  360.  
  361.        There are two extensions for shader parametrization. The
  362.        first is very simple; instead of having to specify a
  363.        pfGeoState for passes of type PF_SHADERPASS_GEOMETRY, it is
  364.        now possible to enable a mode on the pass that will use the
  365.        original pfGeoState of each pfGeoSet that a shader renders.
  366.        This makes it very simple to create a shader which only
  367.        modifies the appearance of objects. The second extension is
  368.        much broader.  OpenGL Performer 2.5 introduces the
  369.        pfNameSpace. pfNameSpace is a facility for attaching any
  370.        named data to any pfObject. For example, a pfTexture can be
  371.        associated with a pfNode under the name "baseTexture". It is
  372.        now possible to create a pfShader which refers to per pass
  373.        attributes by name rather than by reference. For example, a
  374.        pass of type PF_SHADERPASS_COPYPIXELS could refer to the
  375.        name "baseTexture" instead of a pfTexture pointer. When
  376.        pfShaderManager resolves pfShaders on the tree, it maps
  377.        pfShader name references to objects stored in the
  378.        pfNameSpace. With this mechanism, it is possible to
  379.        associate different pfTexture objects with pfNodes under the
  380.        name "baseTexture" and have the shader behave differently
  381.        depending on which "baseTexture" is in scope.
  382.  
  383.        To see further explanations of these extensions, refer to
  384.        these man pages:
  385.        pfShader, pfShaderManager, pfNameSpace, pfFluxedGeoState,
  386.        pfFluxedFBState
  387.  
  388.        For an example, refer to:
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.                                   - 7 -
  401.  
  402.  
  403.  
  404.        /usr/share/Performer/src/pguide/libpf/C++/namespaceShader.C
  405.  
  406.  
  407.        6.4.7.2  _O_p_t_i_m_i_z_e_d__B_u_i_l_t_-_i_n__S_h_a_d_e_r_s
  408.  
  409.        OpenGL Performer 2.5 includes several predefined shaders
  410.        which have been optimized withing the OpenGL Performer
  411.        framework by splitting their work between the CULL and DRAW
  412.        processes. For a description of how to create these shaders,
  413.        refer to the pfShader man page.
  414.  
  415.        OpenGL Performer 2.5 built-in shaders
  416.  
  417.           +o Diffuse Bump mapping
  418.                 /usr/share/Performer/src/pguide/libpf/C++/bumpMap.C
  419.  
  420.           +o Phong Specular Highlighting for one Light
  421.                 /usr/share/Performer/src/pguide/libpf/C++/phong.C
  422.  
  423.           +o Phong Specular Highlighting for multiple Lights:
  424.                 /usr/share/Performer/src/pguide/libpf/C++/multiPhong.C
  425.  
  426.  
  427.  
  428.        6.4.8  _C_l_i_p_-_T_e_x_t_u_r_e__E_m_u_l_a_t_i_o_n
  429.  
  430.        Through software emulation, OpenGL Performer 2.5 now
  431.        supports the majority of the pfClipTexture API on systems
  432.        lacking native support for clip-textures, allowing very
  433.        large texture images to be mapped onto 3-D geometry.
  434.        Cliptexture Emulation is supported on all texture-capable
  435.        IRIX and Linux platforms except InfiniteReality (where
  436.        emulation is not necessary) and RealityEngine.
  437.  
  438.        Man pages to see: pfClipTexture, pfGeoSet
  439.  
  440.        Sample programs to check out:
  441.                /usr/share/Performer/src/sample/C/clipfly
  442.                /usr/share/Performer/src/sample/C++/clipdemo
  443.  
  444.        Loaders that support Emulated Cliptextures:
  445.                /usr/share/Performer/src/lib/libpfdb/libpfct
  446.  
  447.        Available cliptexture data:   (shipped for IRIX only)
  448.                /usr/share/Performer/data/clipdata/moffett
  449.                /usr/share/Performer/data/clipdata/hunter
  450.  
  451.        6.4.9  _E_n_h_a_n_c_e_m_e_n_t_s _t_o _p_f_R_o_t_o_r_W_a_s_h _t_o _o_p_e_r_a_t_e _u_p_o_n _l_a_r_g_e
  452.        _p_o_l_y_g_o_n_s
  453.  
  454.        In OpenGL Performer 2.5 pfRotorWash is enhanced for better
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.                                   - 8 -
  467.  
  468.  
  469.  
  470.        opertion over surface geometry with a large extent.  The
  471.        geometry within the rotorwash diameter is first subdivided
  472.        radially.  Then resulting triangles are further subdivided
  473.        according to the set of radii specified by the user.  The
  474.        user can specify how many of the four radii are used thus
  475.        controlling the number of triangles this subdivision scheme
  476.        may produce.  The rotorwash texture mapped to the resulting
  477.        mesh looks correct even polygons of all sizes.
  478.  
  479.        Man pages to see: pfRotorWash
  480.  
  481.        Sample programs to check out:
  482.                /usr/share/Performer/src/sample/C++/rotorwash
  483.  
  484.  
  485.        6.4.10  _T_h_e__p_f_V_i_e_w_e_r__c_l_a_s_s__a_n_d__l_i_b_p_f_x__l_i_b_r_a_r_y
  486.  
  487.        The pfViewer class is part of a new library (libpfx) which
  488.        dramatically simplifies the writing of OpenGL Performer
  489.        programs by providing a higher level C++ API.
  490.  
  491.        Integration with various GUI toolkits such as OSF/Motif,
  492.        Viewkit and GTK has also been radically simplified by the
  493.        use of higher level classes which abstract away the work
  494.        required to integrate X Toolkits with OpenGL Performer.
  495.        Management of channels, draw callbacks and viewing
  496.        parameters (such as stereo viewing parameters) has also been
  497.        simplified.
  498.  
  499.  
  500.        Man pages to see: pfViewerManager, pfViewer,
  501.                pfSimpleViewer, pfDrawAction, pfGTKViewer,
  502.                pfGUIViewer, pfMotifViewer, pfSimpleDrawAction,
  503.                pfViewkitViewer
  504.  
  505.        Sample programs to check out can be found in the following
  506.        directory:
  507.                /usr/share/Performer/src/pguide/libpfx
  508.  
  509.        The entire source to the libpfx library can also be found in
  510.        the following directory:
  511.                /usr/share/Performer/src/lib/libpfx
  512.  
  513.  
  514.        6.4.11  _R_e_g_i_s_t_e_r__C_o_m_b_i_n_e_r__s_u_p_p_o_r_t__(_L_i_n_u_x__o_n_l_y_)
  515.  
  516.        OpenGL Performer 2.5 supports the application of combiners
  517.        for computing fragment colors using the OpenGL
  518.        NV_register_combiners extension.  This feature can be useful
  519.        for reducing the number of passes in multipass effects.
  520.        Currently, this feature is only available in OpenGL
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.                                   - 9 -
  533.  
  534.  
  535.  
  536.        Performer for Linux.  The API additions are documented in
  537.        the man page and closely follow what is provided by the
  538.        NV_register_combiners extension.
  539.  
  540.        Man pages to see: pfCombiner, pfGeoState
  541.  
  542.        6.4.12  _I_n_t_e_g_r_a_t_i_o_n__w_i_t_h__O_p_e_n_G_L__V_o_l_u_m_i_z_e_r__(_I_R_I_X__O_n_l_y_)
  543.  
  544.        OpenGL Performer 2.5 adds integration with the OpenGL
  545.        Volumizer 2.0 (and later) library through a new file loader,
  546.        libpfvol, as well as a pfGeode subclass to render volumetric
  547.        data called pfVolume.  The pfVolume class is not integrated
  548.        into the main OpenGL Performer library, it is solely
  549.        available through the libpfvol loader.
  550.  
  551.        Using libpfvol, users may load a 3D tiff file with any
  552.        OpenGL Performer based viewer application (e.g. perfly).
  553.        The pfVolume uses the pfGeoSetCB object (describe above)
  554.        which contains a special draw callback to render the
  555.        volumetric data through OpenGL Volumizer.
  556.  
  557.        Prerequisites:  OpenGL Volumizer 2.0 (or later) must be
  558.        installed.
  559.  
  560.        Source code for the libpfvol loader:
  561.                /usr/share/Performer/src/lib/libpfdb/libpfvol/
  562.  
  563.        Documentation to check out:
  564.                /usr/share/Performer/src/lib/libpfdb/libpfvol/README
  565.  
  566.        Data files:
  567.                /usr/share/Performer/data/VolumeData.vol
  568.                /usr/share/Volumizer2/data/medical/Phantom/CT.Head.char.tif
  569.  
  570.        OpenGL Volumizer web site:
  571.                http://www.sgi.com/software/volumizer/
  572.  
  573.  
  574.        6.4.13  _I_n_t_e_g_r_a_t_i_o_n__w_i_t_h__O_p_e_n_G_L__V_i_z_s_e_r_v_e_r
  575.  
  576.        OpenGL Performer 2.5 provides transparent integration with
  577.        OpenGL Vizserver, which enables a single SGI Onyx series
  578.        computer to distribute the visuals of a Performer-based
  579.        simulation to desktop workstations running IRIX, Linux, NT,
  580.        and Solaris.
  581.  
  582.        OpenGL Vizserver web site:
  583.                http://www.sgi.com/software/vizserver/
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.                                   - 10 -
  599.  
  600.  
  601.  
  602.        6.5  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._2
  603.  
  604.        6.5.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._2
  605.  
  606.           +o Multiple pfHyperpipe()/DPLEX groups experienced timing
  607.             delays between pfFrame() and the Channel DRAW Callback.
  608.             This was due to Performer not synchronizing timing
  609.             between hyperpipe groups.  This has been fixed (SCR
  610.             815415).
  611.  
  612.           +o Added support for anisotropic textures in .pfa files.
  613.             They were previously only supported in the .pfb files.
  614.             This has been fixed (SCR 818183).
  615.  
  616.           +o Enabling CPU stats was causing Performer on Linux to
  617.             core dump.  This has been fixed (SCR 820725).
  618.  
  619.           +o Fixed precision issues in pfVolFog with aligning pixel
  620.             copy and polygons covering patchy fog area (no SCR
  621.             number).
  622.  
  623.  
  624.        6.6  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._1
  625.  
  626.        6.6.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._1
  627.  
  628.           +o Intersection testing was limited to geosets with fewer
  629.             than 2^16 triangles.  This limit has been increased to
  630.             2^32 (no SCR number).
  631.  
  632.           +o A successful intersection with an indexed triangle
  633.             strip geoset did not fill the 'prim' field of pfHit.
  634.             This has been fixed (SCR 816478).
  635.  
  636.           +o Intersections and picking with an off-axis viewing
  637.             frustum was not functional.  This has been fixed, in
  638.             both the 2.4.1 and 2.2.12 versions (SCR 803898).
  639.  
  640.           +o Intersection testing with pfDoubleDCS, pfDoubleSCS, or
  641.             pfDoubleFCS nodes was not implemented in Performer 2.4.
  642.             A limited fix has been made, in which single-precision
  643.             versions of the matrices are used for the intersection
  644.             test (no SCR number).
  645.  
  646.           +o DSO IVERSION identifiers specified by Performer had an
  647.             invalid format, sgiX.Y.ABC.  The proper format is
  648.             sgiX.Y.  This could cause applications using the
  649.             backwards-compatibility libraries to fail and has been
  650.             fixed (SCR 816478).
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.                                   - 11 -
  665.  
  666.  
  667.  
  668.           +o Calling pfGetChanESky() before defining a pfEarthSky
  669.             could cause a crash.  This has been fixed (no SCR
  670.             number).
  671.  
  672.           +o Calling pfGetCurLights() before defining any lights
  673.             could cause a crash.  This has been fixed (no SCR
  674.             number).
  675.  
  676.  
  677.        6.6.2  _N_e_w__f_e_a_t_u_r_e_s__a_n_d__i_m_p_r_o_v_e_m_e_n_t_s__i_n__2_._4_._1
  678.  
  679.        6.6.2.1  _p_f_V_o_l_F_o_g
  680.  
  681.        OpenGL Performer 2.4.1 extends the algorithm for rendering
  682.        layered fog by incorporating self-shadowing and scene
  683.        shadowing. The lower parts of a dense fog or objects below a
  684.        dense fog then appear darker.
  685.  
  686.        Self-shadowing is enabled by setting flag 0x40 to 1.  The
  687.        fog mode should be set to PFVFOG_EXP.  If the fog has
  688.        different colors at different elevations and the flag 0x0100
  689.        is set to 1 a secondary scattering of light is approximated.
  690.        In this case the color of higher layers may affect the color
  691.        of lower layers.  If the flag 0x80 is set the scene objects
  692.        below a dense fog become darker.  In all these effects the
  693.        light is assumed to come from the top.
  694.  
  695.  
  696.        6.7  _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _O_p_e_n_G_L _P_e_r_f_o_r_m_e_r _2._4 _a_n_d _I_R_I_S
  697.             _P_e_r_f_o_r_m_e_r _2._2
  698.  
  699.  
  700.  
  701.        6.7.1  _B_e_h_a_v_i_o_r_/_A_P_I__c_h_a_n_g_e_s
  702.  
  703.  
  704.        6.7.1.1  _I_R_I_S__G_L
  705.  
  706.        OpenGL Performer 2.4 supports OpenGL-based rendering only.
  707.        IRIS GL is no longer supported.  Accordingly, the library
  708.        DSO naming scheme has been changed.  What was previously
  709.        _l_i_b_p_f__o_g_l._s_o (for example) is now simply _l_i_b_p_f._s_o.  Be
  710.        certain to update your Makefiles.
  711.  
  712.  
  713.        6.7.1.2  _p_f_d_u_._h__s_t_r_u_c_t_u_r_e_s_:__p_f_d_G_e_o_m_,__p_f_d_P_r_i_m
  714.  
  715.        OpenGL Performer 2.4 changes the structure of pfdPrim and
  716.        pfdGeom in order to support multi-texture. Existing code
  717.        using the prior version of these structures must be ported.
  718.        The struct elements tbind, texCoords, texCoordList,
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.                                   - 12 -
  731.  
  732.  
  733.  
  734.        itexCoords are now arrays of size PF_MAX_TEXTURES.
  735.  
  736.        Porting existing code, the struct members tbind, texCoords,
  737.        texCoordList, itexCoords should be replaced by tbind[0],
  738.        texCoords[0], texCoordList[0], itexCoords[0].
  739.  
  740.        When initializing a pfdPrim struct or when creating a
  741.        pfdGeom struct without the function pfdNewGeom, one must
  742.        initialize the entire array tbind[] to PFGS_OFF as in the
  743.        code example:
  744.  
  745.            {{{{
  746.                iiiinnnntttt        tttt;;;;
  747.                ppppffffddddPPPPrrrriiiimmmm    ****pppp;;;; ////**** OOOOrrrr:::: ppppffffddddGGGGeeeeoooommmm ****pppp;;;; ****////
  748.  
  749.                ffffoooorrrr ((((tttt ==== 0000 ;;;; tttt <<<< PPPPFFFF____MMMMAAAAXXXX____TTTTEEEEXXXXTTTTUUUURRRREEEESSSS ;;;; tttt ++++++++))))
  750.                    pppp---->>>>ttttbbbbiiiinnnndddd[[[[tttt]]]] ==== PPPPFFFFGGGGSSSS____OOOOFFFFFFFF;;;;
  751.            }}}}
  752.  
  753.        6.7.1.3  _p_f_F_l_u_x__d_e_f_a_u_l_t__n_u_m_b_e_r__o_f__b_u_f_f_e_r_s_.
  754.  
  755.        OpenGL Performer 2.4 counts a DBASE process as a pfFlux
  756.        client. Forking a DBASE process increases the default number
  757.        of buffers on a pfFlux by one. Previous versions of OpenGL
  758.        Performer ignored the DBASE process when computing the
  759.        default number of pfFlux buffers.
  760.  
  761.  
  762.        6.7.2  _N_e_w__f_e_a_t_u_r_e_s__a_n_d__i_m_p_r_o_v_e_m_e_n_t_s__i_n__2_._4
  763.  
  764.        6.7.2.1  _E_n_h_a_n_c_e_m_e_n_t_s__t_o__t_h_e__b_a_s_e__l_i_b_r_a_r_y
  765.  
  766.        OpenGL Performer 2.4 introduces many architectural
  767.        improvements to core features in the library, avoiding API
  768.        changes so as to ensure that very little porting effort will
  769.        be required.  These include:
  770.  
  771.           +o Multipipe scalability enhancements.  A significant
  772.             per-pipe overhead in pfFrame() has been removed. This
  773.             enables making many per-frame scene graph changes even
  774.             when using a high number of graphics pipes.
  775.  
  776.           +o Cliptexture performance enhancements.  The texture
  777.             download algorithm has been enhanced to significantly
  778.             improve texture download speed and the accuracy of DTR
  779.             performance.  Refer to
  780.             /usr/share/Performer/src/sample/C++/clipdemo for an
  781.             example.
  782.  
  783.           +o Ability to lock multiple processes on the same
  784.             processor. Avoids deadlocks that used to occur in some
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.                                   - 13 -
  797.  
  798.  
  799.  
  800.             priority configurations.
  801.  
  802.           +o Light-point process enhancements.
  803.  
  804.           +o pfFlux is enhanced.  More detailed explanation has been
  805.             added to the Programmer's Guide.
  806.  
  807.           +o Refer to the detailed notes in the 2.2.x section for
  808.             other enhancements since the 2.2 release.
  809.  
  810.  
  811.        6.7.2.2  _E_n_h_a_n_c_e_m_e_n_t_s__t_o__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__f_o_r__L_i_n_u_x
  812.  
  813.        Because both the IRIX and Linux versions of OpenGL Performer
  814.        share a common code base and API, as enhancements and new
  815.        features are introduced in the IRIX version, they
  816.        simultaneously become available in Linux, and vice versa.
  817.        In addition many internal enhancements have been made in
  818.        OpenGL Performer for Linux to bring its core functionality
  819.        ever closer to that available in IRIX.  Some of the
  820.        enhancements _s_p_e_c_i_f_i_c to OpenGL Performer 2.4 for Linux
  821.        include:
  822.  
  823.           +o Multi-process operation (pfMultiprocess, pfMultithread)
  824.  
  825.           +o Frame-accurate timing control (pfPhase)
  826.  
  827.           +o Anisotropic Texture filtering
  828.  
  829.           +o Multi-Texture support
  830.  
  831.           +o Many performance & feature optimizations, including
  832.             several specific to SGI Linux Desktop workstations.
  833.        These are described in more detail below.
  834.  
  835.  
  836.        6.7.2.3  _N_e_w__f_e_a_t_u_r_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4
  837.  
  838.        OpenGL Performer 2.4 includes revolutionary new support for
  839.        sophisticated model shading, enabling users to render higher
  840.        quality scenes far more easily than coding in OpenGL
  841.        directly.  This release also provides several advanced
  842.        visual effects, to better support simulation applications.
  843.        The new features include:
  844.  
  845.  
  846.        6.7.2.3.1  _p_f_S_h_a_d_e_r
  847.  
  848.        pfShader is a new approach to dramatically simplify OpenGL
  849.        multi-pass rendering creation.  Instead of writing direct
  850.        OpenGL code using pfDraw callbacks and draw bins, users can
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.                                   - 14 -
  863.  
  864.  
  865.  
  866.        take advantage of the easy to use OpenGL Shader to create
  867.        the same effects at modeling time.
  868.  
  869.        OpenGL Shader is a powerful appearance-modeling tool.  Using
  870.        the Shader language and compiler, users can easily create
  871.        shaders that describe very sophisticated multi-pass
  872.        rendering effects. Read http://www.sgi.com/software/shader/
  873.        for details on OpenGL Shader. The shaders can be associated
  874.        with any pfNode in the OpenGL Performer scene graph to
  875.        achieve high performance multi-passing rendering results
  876.        using OpenGL Performer without writing OpenGL code directly.
  877.  
  878.        pfShader in 2.4 is our first effort at supporting OpenGL
  879.        Shader within OpenGL Performer. The purpose is to establish
  880.        the architecture foundation for this revolutionary approach.
  881.        There are still many limitations in the pfShader.  Not all
  882.        shaders created from OpenGL Shader can be supported in 2.4,
  883.        for example, shaders with variable changes.  Further
  884.        extensions and performance enhancements will become
  885.        available in future regular releases.
  886.  
  887.        Man pages to see: pfShader, pfShaderManager
  888.  
  889.        Sample programs to check out:
  890.  
  891.                /usr/share/Performer/src/pguide/libpf/C++/shader_blue_and_purple.C
  892.                /usr/share/Performer/src/pguide/libpf/C++/shader_multiple_shaders.C
  893.                /usr/share/Performer/src/pguide/libpf/C++/shader_multiple_shaders.C
  894.                /usr/share/Performer/src/pguide/libpf/C++/shader_red_material.C
  895.                /usr/share/Performer/src/pguide/libpf/C++/shader_test.C
  896.                /usr/share/Performer/src/pguide/libpf/C++/shader_wood_texture.C
  897.  
  898.        Utilities to use:
  899.  
  900.                /usr/share/Performer/src/tools/ipf2pf (convert
  901.        shader file into pfShader file)
  902.                /usr/share/Performer/src/lib/libpfdb/libpfpfs
  903.                /usr/share/Performer/src/lib/libpfdb/libpfpfb
  904.  
  905.        Documentation to use in addtion to Programmer's Guide:
  906.                /usr/share/Performer/src/tools/pfshader_file_spec.txt
  907.  
  908.        pfShader Data:
  909.  
  910.                /usr/share/Performer/data/shaderExample.pfb
  911.                /usr/share/Performer/data/shaders/*.shader
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.                                   - 15 -
  929.  
  930.  
  931.  
  932.        6.7.2.3.2  _M_u_l_t_i-_p_r_o_c_e_s_s _o_p_e_r_a_t_i_o_n _i_n _L_i_n_u_x (_F_U_L_L _E_D_I_T_I_O_N
  933.        _o_n_l_y)
  934.  
  935.        OpenGL Performer 2.4 for Linux now supports the complete
  936.        App/Cull/Draw/Isect/Compute/Dbase/Input multiprocessing
  937.        capabilities of OpenGL Performer for IRIX.  Likewise, the
  938.        underlying IRIX shared arena, locks, and IPC management
  939.        routines such as ussetlock(), usunsetlock() are available
  940.        for developer application through /usr/include/ulocks.h.
  941.  
  942.  
  943.        6.7.2.3.3  _F_r_a_m_e_-_a_c_c_u_r_a_t_e__t_i_m_i_n_g__c_o_n_t_r_o_l__i_n__L_i_n_u_x
  944.  
  945.        OpenGL Performer 2.4 for Linux now supports the complete
  946.        FREE_RUN/LIMIT/FLOAT/LOCK pfPhase() functionality of OpenGL
  947.        Performer for IRIX.  Note that phase control is currently
  948.        implemented as an emulation timing layer which does not yet
  949.        support swapbuffer synchronization to the vertical retrace;
  950.        If your graphics card currently supports synchronization to
  951.        vertical retrace, Phase control may be off by one video
  952.        field.  This will be corrected as OpenGL driver improvements
  953.        allow.
  954.  
  955.  
  956.        6.7.2.3.4  _M_u_l_t_i_-_t_e_x_t_u_r_e
  957.  
  958.        OpenGL Performer 2.4 supports the application of multiple
  959.        texture maps on a single polygon using the OpenGL multi-
  960.        texture extension.  Currently, this feature is only
  961.        available in OpenGL Performer for Linux.  pfGeoSet now
  962.        accepts multiple texture coordinate arrays, and pfGeoState
  963.        now accepts multiple pfTexture, pfTexGen, pfTexLOD, texture
  964.        matrices and detail textures.  The API additions are very
  965.        straightforward.
  966.  
  967.        Man pages to see: pfGeoSet, pfGeoState
  968.  
  969.        Sample programs to check out:
  970.  
  971.                /usr/share/Performer/src/pguide/libpf/C/multiTexBox.c
  972.                /usr/share/Performer/src/pguide/libpf/C/multiTexBox_flux.c
  973.  
  974.        Utilities to use:
  975.  
  976.                /usr/share/Performer/src/lib/libpfdu/pfdBuilder.c
  977.                /usr/share/Performer/src/lib/libpfdu/pfdTMesher.c
  978.                /usr/share/Performer/src/lib/libpfutil/hash.c
  979.                /usr/share/Performer/src/lib/libpfdu/pfdGeoBuilder.c
  980.                /usr/share/Performer/src/lib/libpfdu/pfdRebuild.c
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.                                   - 16 -
  995.  
  996.  
  997.  
  998.        Loaders that support multi-texture data: Flight loader, pfb
  999.        loader
  1000.  
  1001.  
  1002.        6.7.2.3.5  _A_n_i_s_o_t_r_o_p_i_c__f_i_l_t_e_r
  1003.  
  1004.        Standard mipmap filtering can induce blurring on a texture
  1005.        if the texture is applied to a polygon which is angled away
  1006.        from the viewer.  To reduce this blurring, an anisotropic
  1007.        filter can be used to improve visual quality.  The
  1008.        anisotropic filter is only available on Linux systems.
  1009.  
  1010.        Man pages to see: pfTexture
  1011.  
  1012.        Sample programs to check out:
  1013.  
  1014.                /usr/share/Performer/src/pguide/libpf/C/anisotropic.c
  1015.                /usr/share/Performer/src/pguide/libpf/C++/anisotropic.C
  1016.  
  1017.  
  1018.        6.7.2.3.6  _V_o_l_u_m_e__f_o_g
  1019.  
  1020.        pfVolFog is a new class that uses a multi-pass algorithm to
  1021.        draw the scene with fog that has different densities at
  1022.        different locations. It extends the basic layered fog
  1023.        provided by pfEarthSky and it supports two types of fog:
  1024.        layered fog and patchy fog.
  1025.  
  1026.        Layered fog changes only with elevation, its density and
  1027.        color is uniform at a given height. It is defined by a set
  1028.        of elevation points, each specifying a fog density and
  1029.        optionally also a fog color at the point's elevation.  The
  1030.        density and the color between two neighboring points is
  1031.        linearly interpolated.  Patchy fog has a constant density in
  1032.        a given area. The boundaries of this area can be defined by
  1033.        an arbitrary three-dimensional object or a set of objects.
  1034.  
  1035.        Man pages to see: pfVolFog
  1036.  
  1037.        Demos to check out:
  1038.  
  1039.                /usr/share/Performer/src/sample/C++/volfog
  1040.                /usr/share/Performer/src/sample/C/fogfly
  1041.  
  1042.  
  1043.        6.7.2.3.7  _R_o_t_o_r__W_a_s_h
  1044.  
  1045.        A pfRotorwash is used to create a graph including geometry
  1046.        and pfState which represents the visual downwash effect on
  1047.        terrain or water. The geometry changes dynamically with the
  1048.        scene and position from which it is generated. Users who are
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.                                   - 17 -
  1061.  
  1062.  
  1063.  
  1064.        developing helicopter demos are especially encouraged to try
  1065.        out this feature.
  1066.  
  1067.        Man pages to see: pfRotorwash
  1068.  
  1069.        Demos to check out:
  1070.  
  1071.                /usr/share/Performer/src/sample/C++/rotorwash
  1072.  
  1073.  
  1074.        6.7.2.3.8  _D_o_u_b_l_e__p_r_e_c_i_s_i_o_n__m_a_t_r_i_x__s_u_p_p_o_r_t   Double
  1075.        precision matrix operations are supported in this release.
  1076.        This feature is extremely helpful when rendering large
  1077.        databases where objects can be very far away from the
  1078.        origin.
  1079.  
  1080.        Man pages to see: pfDoubleDCS, pfDoubleFCS, pfDoubleSCS
  1081.  
  1082.        Sample programs to check out:
  1083.  
  1084.                /usr/share/Performer/src/pguide/libpf/C/doubleDCS.c
  1085.                /usr/share/Performer/src/pguide/libpf/C/doubleDCS2.c
  1086.  
  1087.        Demos to check out:
  1088.  
  1089.                /usr/share/Performer/src/sample/C/clipfly
  1090.  
  1091.  
  1092.        6.7.2.3.9  _A_b_i_l_i_t_y _t_o _l_o_c_k _m_u_l_t_i_p_l_e _p_r_o_c_e_s_s_e_s _o_n _t_h_e _s_a_m_e
  1093.        _p_r_o_c_e_s_s_o_r.   OpenGL Performer 2.4 adds new API for
  1094.        eliminating frame glitches when locking multiple processes
  1095.        on one processor. This API enables a temporary priority
  1096.        upgrade for low priority processes when the APP process
  1097.        waits for them.
  1098.  
  1099.        Man pages to see: pfProcessPriorityUpgrade,
  1100.        pfProcessHighestPriority
  1101.  
  1102.  
  1103.        6.7.2.3.10  _D_P_L_E_X__s_u_p_p_o_r_t
  1104.  
  1105.        Refer to the description under 2.2.4 for details.
  1106.  
  1107.  
  1108.        6.7.2.3.11  _L_O_D__e_v_a_l_u_a_t_i_o_n__f_u_n_c_t_i_o_n
  1109.  
  1110.        pfLOD is extended to take a user function for picking an LOD
  1111.        result. The result of this user function is a floating point
  1112.        number. This gives users ultimate flexibility in LOD
  1113.        evaluation.
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.                                   - 18 -
  1127.  
  1128.  
  1129.  
  1130.        Man pages to see: pfLOD
  1131.  
  1132.  
  1133.        6.8  _D_i_f_f_e_r_e_n_c_e__b_e_t_w_e_e_e_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._3__a_n_d__2_._2
  1134.  
  1135.        IRIS Performer 2.3 was the first release of Performer for
  1136.        Linux.  Please refer to the OpenGL Performer website for
  1137.        details.
  1138.  
  1139.  
  1140.        6.9  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1_0
  1141.  
  1142.        6.9.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1_0
  1143.  
  1144.           +o The IRIX PFB file loader was unable to read PFB files
  1145.             generated on Linux-based systems due to file
  1146.             endianness.  This has been fixed (SCR 786258).
  1147.  
  1148.           +o Performer serialized the rendering of each pfPipe on
  1149.             multi-pipe systems running in "Multi-Keyboard" or "TKO"
  1150.             mode.  This has been fixed (SCR 791376).
  1151.  
  1152.  
  1153.        6.10  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._9
  1154.  
  1155.        6.10.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._9
  1156.  
  1157.           +o Calligraphic light points flash in certain multipipe
  1158.             configurations.  This is the case even in
  1159.             PF_LPOINT_BOARD emulation mode.
  1160.  
  1161.             Each calligraphic board (including the simulated one)
  1162.             has some amount of memory which is used to specify
  1163.             light points. When performer fills up this memory
  1164.             buffer, meaning that the board can not take more input,
  1165.             it will render the remaining points in software mode.
  1166.             lpoints rendered in software mode occupy more pixels on
  1167.             screen than lpoints rendered in hardware mode, hence
  1168.             the flashing behavior. The problem is due to the fact
  1169.             that Performer's memory book-keeping for lpoint buffers
  1170.             breaks under a couple conditions:
  1171.  
  1172.             1) When at least one pipe is doing calligraphics but
  1173.             pipe 0 is not 2) When calligraphics are used on non-
  1174.             consecutive pipes
  1175.  
  1176.             These memory book-keeping problems have been fixed in
  1177.             2.2.9 (SCR 787645).
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.                                   - 19 -
  1193.  
  1194.  
  1195.  
  1196.        6.11  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  1197.  
  1198.        6.11.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  1199.  
  1200.           +o Access into Shared Memory pages is slow the first time
  1201.             each page is accessed.  This is particularly noticeable
  1202.             when paging ClipTextures.  A workaround has been
  1203.             implemented (see 'New Features' below).  SCR 606004.
  1204.  
  1205.           +o pfFindNode/pfLookupNode cannot find a pfGeode with
  1206.             pfNode type, though the manpage says that Performer
  1207.             uses pfIsOfType instead of pfIsExactType for those
  1208.             functions.  This has been fixed so that
  1209.             pfNode/pfLookupNode use pfIsOfType instead of
  1210.             pfIsExactType semantics (SCR 774905).
  1211.  
  1212.           +o
  1213.  
  1214.           +o The pfb loader leaks memory when a texture image file
  1215.             is not available. Loading and deleting a model with one
  1216.             texture image file missing leaks sizeof(pfTexture)
  1217.             bytes.
  1218.  
  1219.  
  1220.        6.11.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  1221.  
  1222.        6.11.2.1  _A_r_e_n_a__P_a_g_e__E_x_e_r_c_i_s_i_n_g
  1223.  
  1224.           +o When a forked process accesses memory in the shared
  1225.             arena, the first time it accesses each page is much
  1226.             slower than accessing that page subsequently. This
  1227.             problem becomes very pronounced when the forked process
  1228.             is striding through a large number of pages, such as
  1229.             sending large amounts of texture from the arena to the
  1230.             pipes, as is the case with cliptexturing.  In this
  1231.             case, the application will experience performance
  1232.             glitches when memory regions are accessed for the first
  1233.             time.
  1234.  
  1235.             The workaround for this problem is to access a memory
  1236.             location in each page of the arena during program
  1237.             startup. This workaround makes most sense in the DRAW
  1238.             process, since it's the one that's affected most due to
  1239.             its access of large amounts of texture data.
  1240.  
  1241.             Performer 2.2.8 will touch each arena page in each draw
  1242.             process if the environment variable
  1243.             "_PFDRAW_EXERCISE_ARENA" is set. If the environment
  1244.             variable is set to a numerical value, each draw process
  1245.             will run through the arena the specified number of
  1246.             times, reporting how long it took to touch all the
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.                                   - 20 -
  1259.  
  1260.  
  1261.  
  1262.             pages in each iteration. It's not necessary to touch
  1263.             each page more than once except to see the difference
  1264.             in access times to those pages.
  1265.  
  1266.  
  1267.        6.11.2.2  _S_u_p_p_o_r_t__f_o_r__n_e_w__O_c_t_a_n_e__g_r_a_p_h_i_c_s__h_a_r_d_w_a_r_e
  1268.  
  1269.           +o Performer 2.2.8 introduces support for the new Octane
  1270.             graphics hardware. If this hardware is detected,
  1271.             Performer will use OpenGL features that are on the fast
  1272.             path for this system, just as with other supported
  1273.             hardware.
  1274.  
  1275.  
  1276.        6.11.2.3  _P_o_s_t__l_p_o_i_n_t_-_d_r_a_w__c_a_l_l_b_a_c_k
  1277.  
  1278.           +o Some applications need to draw to the frame buffer
  1279.             after all other drawing has occurred. In the case where
  1280.             applications uses a forked LPOINT process, the drawing
  1281.             of light points happens after the draw callback is
  1282.             invoked, making it difficult to draw something on top
  1283.             of the light points.
  1284.  
  1285.             To get around this problem, Performer 2.2.8 now
  1286.             supports a post-lpoint-draw callback on pfChannels. To
  1287.             add such a callback to a pfChannel, use the
  1288.             "PFTRAV_POSTLPOINT" token to pfChannel::setTravFunc or
  1289.             pfChanTravFunc, for example:
  1290.  
  1291.  
  1292.             cccchhhhaaaannnnnnnneeeellll---->>>>sssseeeettttTTTTrrrraaaavvvvFFFFuuuunnnncccc((((PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT,,,, ppppoooossssttttDDDDrrrraaaawwwwFFFFuuuunnnncccc))));;;;
  1293.  
  1294.             The callback will be invoked regardless of
  1295.             multiprocessing mode. In applications which fork the
  1296.             LPOINT process, it will be called after the last light
  1297.             point has been drawn in each channel. In applications
  1298.             which do not fork the LPOINT process, the post-lpoint-
  1299.             draw callback will be invoked immediately after the
  1300.             draw callback returns. This callback is not reflected
  1301.             in the stats.
  1302.  
  1303.             Since Performer 2.2.8 is an eoe update, we can not
  1304.             distribute header files, so to use the FTRAV_POSTLPOINT
  1305.             token, you must define it. Include the following lines
  1306.             in files using the token:
  1307.  
  1308.  
  1309.             ####iiiiffffnnnnddddeeeeffff PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT
  1310.             ####ddddeeeeffffiiiinnnneeee PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT 6666
  1311.             ####eeeennnnddddiiiiffff
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.                                   - 21 -
  1325.  
  1326.  
  1327.  
  1328.        6.12  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._7
  1329.  
  1330.        6.12.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._7
  1331.  
  1332.           +o Triangle fans were not being correctly reported by the
  1333.             stats.  This has been fixed (SCR 769104).
  1334.  
  1335.           +o An array bounds underrun in _pfCuller::pf_applyXform
  1336.             could lead to memory corruption.  This has been fixed
  1337.             (SCR 767432).
  1338.  
  1339.           +o The prototype for pfDTRApplyImageCache was incorrectly
  1340.             documented.  This has been fixed (SCR 752840).
  1341.  
  1342.           +o pfNode::bufferClone could cause a segmentation
  1343.             violation.  This has been fixed (SCR 695725).
  1344.  
  1345.           +o The channel frustum type was being reset by
  1346.             pfChannel::pf_cullShadows.  This has been fixed (SCR
  1347.             679085).
  1348.  
  1349.           +o A memory leak caused by multi-pipe pfImageCache
  1350.             invalidation has been fixed.
  1351.  
  1352.  
  1353.        6.13  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  1354.  
  1355.        6.13.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  1356.  
  1357.           +o A change in the semantics of sginap() could cause
  1358.             frames to be missed if the application was running in
  1359.             FLOAT or LOCK phase and finishing its frame more than a
  1360.             full video field early.  See Chapter 4 of these release
  1361.             notes for more details.  This has been fixed in IRIX
  1362.             6.5.5 (SCR 635983).
  1363.  
  1364.           +o A math error when in multipass lighting mode caused
  1365.             infinite lights (those with a w coordinate of 0) to be
  1366.             transformed incorrectly through the modelview matrix,
  1367.             producing incorrect lighting results.  This has been
  1368.             fixed.
  1369.  
  1370.           +o A reversed cross product caused the
  1371.             pfLightSource::setSpotDir call to rotate the light in
  1372.             the wrong direction in some cases.  This has been
  1373.             fixed.
  1374.  
  1375.        6.13.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.                                   - 22 -
  1391.  
  1392.  
  1393.  
  1394.        6.13.2.1  _M_u_l_t_i_p_a_s_s__L_i_g_h_t_i_n_g
  1395.  
  1396.           +o The multipass implementation introduced in 2.2.5 did
  1397.             not support fog-based range attenuation of projective
  1398.             lights.  This feature is now supported.
  1399.  
  1400.           +o Prior releases cleared the color buffer to red when
  1401.             generating the shadow maps for shadow-casting lights.
  1402.             Code which assumed that the shadowmap generation pass
  1403.             would clear the framebuffer to black produced incorrect
  1404.             results, so this behavior has been changed; The color
  1405.             buffer is now cleared to black when rendering the
  1406.             shadow map.  Note:  No assumptions should be made about
  1407.             the contents of the color buffer between shadowmap and
  1408.             scene rendering; always clear the color buffer when
  1409.             unsure of its contents.
  1410.  
  1411.  
  1412.        6.14  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  1413.  
  1414.        6.14.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  1415.  
  1416.           +o pfFrustum::makeOrtho() calculated incorrect near/far
  1417.             clip plane values.  This has been fixed (SCR 658920).
  1418.  
  1419.           +o pfGetStage() could return incorrect values due to the
  1420.             Performer clock being included in the process list.
  1421.             This has been fixed (SCR 668773).
  1422.  
  1423.           +o Channel-CULL callbacks registered from the .ct loader
  1424.             could collide when used in multi-channel
  1425.             configurations, resulting in the incorrect calculations
  1426.             of texture coordinates.  This regression has been fixed
  1427.             (SCR 668222).
  1428.  
  1429.           +o perfly, asdfly, and clipfly could not configure multi-
  1430.             hyperpipe systems.  This capability has been added (SCR
  1431.             675711).
  1432.  
  1433.           +o Draw statistics were only being accumulated for the
  1434.             first pipe in a hyperpipe group.  This has been fixed
  1435.             (SCR 675517).
  1436.  
  1437.           +o A garbage frame would sometimes be seen when using
  1438.             texture from a DIVO source in Performer on Onyx2
  1439.             systems with 'Reality' graphics.  This was due to a
  1440.             mismatch in Performer's automatic detection of graphics
  1441.             type and has been fixed (SCR 671095).
  1442.  
  1443.           +o The default displacement offset for coplanar polygons
  1444.             was set too large for small frusta.  This has been
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.                                   - 23 -
  1457.  
  1458.  
  1459.  
  1460.             fixed (SCR 625598, 670200).  See below for
  1461.             configuration details.
  1462.  
  1463.           +o Several additional improvements to the multipass
  1464.             algorithm used for projective texture pfLightSources
  1465.             have been made in 2.2.5.  In particular, the algorithm
  1466.             now supports geometry with texture based transparency
  1467.             (for example, a tree billboard).
  1468.  
  1469.        6.14.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  1470.  
  1471.        6.14.2.1  _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L__1_._1__g_l_P_o_l_y_g_o_n_O_f_f_s_e_t_(_)
  1472.  
  1473.        This release modifies the routines used for coplanar polygon
  1474.        displacement to one based upon the polygon offset
  1475.        functionality in OpenGL 1.1.  The changes apply to all
  1476.        platforms using OpenGL 1.1 except the Impact series.
  1477.  
  1478.        Users may revert to the prior (Performer 2.2) behavior by
  1479.        setting the environment variable
  1480.        PF_FORCE_EXT_POLYGON_OFFSET.
  1481.  
  1482.        Likewise, users may choose to force the new functionality to
  1483.        be used on Impact systems (despite known bugs at this time)
  1484.        by setting the environment variable
  1485.        PF_FORCE_ARB_POLYGON_OFFSET.
  1486.  
  1487.        In case the results of the new offset behavior are not ideal
  1488.        for a particular system or database, users may tune the
  1489.        values set internally by IRIS Performer.  The environment
  1490.        variables PF_ARB_POLYGON_OFFSET_FACTOR and
  1491.        PF_ARB_POLYGON_OFFSET_UNITS can be set to floating point
  1492.        values which will then be used internally as arguments to
  1493.        glPolygonOffset().  See the glPolygonOffset(3G) man page for
  1494.        further details of the effect of these settings.
  1495.  
  1496.        Although the OpenGL 1.1 glPolygonOffset() changes were
  1497.        intended to resolve machine dependency issues, please note
  1498.        that the ideal offset factor and units value may still vary
  1499.        from system to system.  The glPolygonOffset() values set by
  1500.        IRIS Performer were chosen for typical database settings on
  1501.        InfiniteReality systems and may require adjustment on other
  1502.        OpenGL 1.1 systems, using the environment variables
  1503.        described above.
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.                                   - 24 -
  1523.  
  1524.  
  1525.  
  1526.        6.15  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  1527.  
  1528.        6.15.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  1529.  
  1530.           +o The Performer signal handler would enter an infinite
  1531.             loop if a process forked or sproc'd from the APP
  1532.             process exited.  This has been fixed (SCR 651566).
  1533.  
  1534.           +o Setting the PF_LPOINT_BOARD environment variable to
  1535.             enable emulation of calligraphic hardware (by using
  1536.             standard raster light points) had no effect.  This has
  1537.             been fixed (SCR 615443).
  1538.  
  1539.           +o Threading the lightpoint process caused a segmentation
  1540.             fault.  This has been fixed.
  1541.  
  1542.           +o Models containing pfLightPoints with a NULL
  1543.             pfLPointState could cause a segmentation violation on
  1544.             O2 systems running IRIX 6.5.2.  This has been fixed
  1545.             (SCR 614274).
  1546.  
  1547.           +o Several improvements to the multipass algorithm used
  1548.             for projective texture pfLightSources have been made.
  1549.             Colored spotlights now interact correctly with each
  1550.             other.  Note that the current algorithm does not
  1551.             support geometry with texture based transparency (for
  1552.             example, a tree billboard), and can only produce
  1553.             translucent geometry on systems with multisampling
  1554.             capability.
  1555.  
  1556.           +o Several pfStats::query() tokens were unimplemented.
  1557.             Most of the missing tokens can now be used to query
  1558.             statistics.  The following will still return an error:
  1559.  
  1560.                +o PFSTATSVAL_CPU_SECS
  1561.                  PFSTATSVAL_CPU_GFX_SWAPBUFFERS
  1562.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE
  1563.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_HOST
  1564.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_XFORM
  1565.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_FILL
  1566.                  PFSTATSVAL_GFXPIPE_TIMES_SECS
  1567.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_HOST
  1568.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_XFORM
  1569.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_FILL
  1570.  
  1571.           +o IRIX 6.5 introduced support for the concurrent use of
  1572.             shared arenas and POSIX threads (pthreads), however
  1573.             there was an error in the GLX implementation which
  1574.             prevented IRIS Performer applications from opening a
  1575.             window if the pthread library was linked.  The GLX
  1576.             implementation in the IRIX 6.5.3 overlay has addressed
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.                                   - 25 -
  1589.  
  1590.  
  1591.  
  1592.             this problem, so IRIS Performer applications can now be
  1593.             safely used with pthreads.
  1594.  
  1595.           +o The CSB loader has been updated to enable the use of
  1596.             ClearCoat(tm).
  1597.  
  1598.           +o Graphics state information could "leak" from a
  1599.             cliptexture to other models in the scene.  This has
  1600.             been fixed (SCR 603185).
  1601.  
  1602.  
  1603.        6.15.2  _N_e_w__F_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  1604.  
  1605.        6.15.2.1  _S_u_p_p_o_r_t__f_o_r__D_P_L_E_X__o_p_t_i_o_n
  1606.  
  1607.        Performer 2.2.4 includes support for the DPLEX option to
  1608.        Onyx2 Infinite Reality. This support has been affected
  1609.        without changes to the API, and modifications to the
  1610.        command-line options for perfly, clipfly, and asdfly have
  1611.        been made to enable DPLEX. There are, however, some changes
  1612.        to the semantics of _p_f_P_i_p_e, _p_f_P_i_p_e_W_i_n_d_o_w, and _p_f_C_h_a_n_n_e_l
  1613.        interaction.  This change is described below.
  1614.  
  1615.        Initialization of the hyperpipe is via the existing
  1616.        pfHyperpipe() API.  This call defines the number of _p_f_P_i_p_es
  1617.        to combine into a single hyperpipe.  Each call to
  1618.        pfHyperpipe() defines a separate hyperpipe instance. For
  1619.        example, two calls to pfHyperpipe() with an argument of 2
  1620.        would define two hyperpipes of 2 _p_f_P_i_p_es each to Performer.
  1621.        Like pfMultipipe(), this routine can only be invoked prior
  1622.        to pfConfig().  Additionally, the _p_f_P_i_p_es of the hyperpipes
  1623.        will be the lowest numbered _p_f_P_i_p_es, with any non-hyperpipe
  1624.        _p_f_P_i_p_es appearing at the end.
  1625.  
  1626.        The first (lowest numbered) _p_f_P_i_p_e of the hyperpipe is the
  1627.        master.  In the above example, that would be _p_f_P_i_p_es 0 and
  1628.        2.  All control of the hyperpipe should be made through the
  1629.        master _p_f_P_i_p_e. For example, to construct a _p_f_P_i_p_e_W_i_n_d_o_w for
  1630.        a hyperpipe, the application can simply create it on the
  1631.        master _p_f_P_i_p_e. The cloned _p_f_P_i_p_e_W_i_n_d_o_ws for each _p_f_P_i_p_e in
  1632.        the hyperpipe will be created automatically. While allowed,
  1633.        constructing a _p_f_P_i_p_e_W_i_n_d_o_w on a non-master pipe of the
  1634.        hyperpipe will lead to undefined results.
  1635.  
  1636.        Hyperpipes differ from other multipipe configurations in one
  1637.        other very important way. The set of _p_f_C_h_a_n_n_e_l_s displayed on
  1638.        the hyperpipe is shared amongst all of the _p_f_P_i_p_e_s in the
  1639.        hyperpipe.  That is, it is only necessary to create and set
  1640.        _p_f_C_h_a_n_n_e_l objects on the master _p_f_P_i_p_e of the hyperpipe.
  1641.        Since the hyperpipe is a time multiplexed view of these
  1642.        channels, Performer will propagate changes in the _p_f_C_h_a_n_n_e_l
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.                                   - 26 -
  1655.  
  1656.  
  1657.  
  1658.        to each of the _p_f_P_i_p_e_s in turn.
  1659.  
  1660.        The following code snippet identifies the steps needed to
  1661.        setup a multi-hyperpipe config. It assumes that each of the
  1662.        hyperpipes are symetric (i.e., have the same number of
  1663.        pipes), although this is not required by Performer.
  1664.  
  1665.  
  1666.        ////****
  1667.         **** LLLLooooccccaaaallll ddddeeeeccccllllaaaarrrraaaattttiiiioooonnnnssss
  1668.         ****////
  1669.        iiiinnnntttt iiii;;;;
  1670.        ppppffffCCCChhhhaaaannnnnnnneeeellll**** mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn;;;;
  1671.        ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn;;;;
  1672.  
  1673.        ////****
  1674.         **** TTTThhhheeee ffffoooolllllllloooowwwwiiiinnnngggg aaaassssssssuuuummmmeeeessss tttthhhhaaaatttt hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr ooooffff
  1675.         **** hhhhyyyyppppeeeerrrrppppiiiippppeeeessss ttttoooo ccccoooonnnnffffiiiigggguuuurrrreeee aaaannnndddd hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr
  1676.         **** ppppiiiippppeeeessss ppppeeeerrrr hhhhyyyyppppeeeerrrrppppiiiippppeeee....
  1677.         ****////
  1678.        iiiinnnntttt ppppiiiippppeeeeCCCCoooouuuunnnntttt ==== hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt****hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt;;;;
  1679.  
  1680.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
  1681.            ppppffffHHHHyyyyppppeeeerrrrppppiiiippppeeee((((hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt))));;;;
  1682.  
  1683.        ////****
  1684.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr
  1685.         ****////
  1686.        ppppffffCCCCoooonnnnffffiiiigggg(((())));;;;
  1687.  
  1688.        ////****
  1689.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee tttthhhheeee ssssccccrrrreeeeeeeennnnssss ffffoooorrrr tttthhhheeee ppppffffPPPPiiiippppeeeessss
  1690.         ****
  1691.         **** AAAAssssssssuuuummmmeeeessss aaaallllllll ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy aaaannnndddd ssssccccrrrreeeeeeeennnn aaaassssssssiiiiggggnnnnmmmmeeeennnnttttssss tttthhhhaaaatttt mmmmaaaapppp
  1692.         **** ttttoooo ppppffffPPPPiiiippppeeee nnnnuuuummmmbbbbeeeerrrr
  1693.         ****////
  1694.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
  1695.            ppppffffPPPPiiiippppeeeeSSSSccccrrrreeeeeeeennnn((((ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii)))),,,, iiii))));;;;  //////// aaaassssssssuuuummmmeeeessss aaaallllllll oooonnnn ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy
  1696.  
  1697.        ////****
  1698.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee aaaa tttthhhhrrrreeeeeeee,,,, ttttwwwwoooo----ppppiiiippppeeee hhhhyyyyppppeeeerrrrppppiiiippppeeee ffffoooorrrr mmmmuuuullllttttiiii----cccchhhhaaaannnnnnnneeeellll ddddiiiissssppppllllaaaayyyy....
  1699.         ****////
  1700.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii ++++==== hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt)))) {{{{
  1701.            ppppffffPPPPiiiippppeeee**** pppp;;;;
  1702.            ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** ppppwwww;;;;
  1703.            ppppffffCCCChhhhaaaannnnnnnneeeellll**** cccchhhhaaaannnn;;;;
  1704.            iiiinnnntttt sssshhhhaaaarrrreeee;;;;
  1705.            PPPPFFFFVVVVEEEECCCC3333 xxxxyyyyzzzz,,,, hhhhpppprrrr;;;;
  1706.  
  1707.            pppp ==== ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii))));;;;
  1708.            ppppwwww ==== ppppffffNNNNeeeewwwwPPPPWWWWiiiinnnn((((pppp))));;;;
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.                                   - 27 -
  1721.  
  1722.  
  1723.  
  1724.            ppppffffPPPPWWWWiiiinnnnNNNNaaaammmmeeee((((ppppwwww,,,, """"HHHHyyyyppppeeeerrrrppppiiiippppeeee WWWWiiiinnnnddddoooowwww""""))));;;;
  1725.            ppppffffPPPPWWWWiiiinnnnCCCCoooonnnnffffiiiiggggFFFFuuuunnnncccc((((ppppwwww,,,, OOOOppppeeeennnnPPPPiiiippppeeeeWWWWiiiinnnn))));;;;
  1726.            ppppffffPPPPWWWWiiiinnnnTTTTyyyyppppeeee((((ppppwwww,,,, PPPPFFFFPPPPWWWWIIIINNNN____TTTTYYYYPPPPEEEE____XXXX))));;;;
  1727.            ppppffffPPPPWWWWiiiinnnnFFFFuuuullllllllSSSSccccrrrreeeeeeeennnn((((ppppwwww))));;;;
  1728.            ppppffffPPPPWWWWiiiinnnnMMMMooooddddeeee((((ppppwwww,,,, PPPPFFFFWWWWIIIINNNN____NNNNOOOOBBBBOOOORRRRDDDDEEEERRRR,,,, 1111))));;;;
  1729.            ppppffffCCCCoooonnnnffffiiiiggggPPPPWWWWiiiinnnn((((ppppwwww))));;;;
  1730.            iiiiffff ((((iiii ======== 0000)))) mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn ==== ppppwwww;;;;
  1731.  
  1732.            cccchhhhaaaannnn ==== ppppffffNNNNeeeewwwwCCCChhhhaaaannnn((((pppp))));;;;
  1733.            sssshhhhaaaarrrreeee ==== ppppffffGGGGeeeettttCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn))));;;;
  1734.            sssshhhhaaaarrrreeee ||||==== PPPPFFFFCCCCHHHHAAAANNNN____VVVVIIIIEEEEWWWWPPPPOOOORRRRTTTT |||| PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS ||||
  1735.                     PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS____HHHHWWWW;;;;
  1736.            ppppffffCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn,,,, sssshhhhaaaarrrreeee))));;;;
  1737.            ppppffffMMMMaaaakkkkeeeeSSSSiiiimmmmpppplllleeeeCCCChhhhaaaannnn((((cccchhhhaaaannnn,,,, 44445555))));;;;
  1738.            ppppffffCCCChhhhaaaannnnAAAAuuuuttttooooAAAAssssppppeeeecccctttt((((cccchhhhaaaannnn,,,, PPPPFFFFFFFFRRRRUUUUSSSSTTTT____CCCCAAAALLLLCCCC____VVVVEEEERRRRTTTT))));;;;
  1739.            ppppffffAAAAddddddddCCCChhhhaaaannnn((((ppppwwww,,,, cccchhhhaaaannnn))));;;;
  1740.  
  1741.            ppppffffSSSSeeeettttVVVVeeeecccc3333((((xxxxyyyyzzzz,,,, 0000,,,, 0000,,,, 0000))));;;;
  1742.            ppppffffSSSSeeeettttVVVVeeeecccc3333((((hhhhpppprrrr,,,, ((((((((hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt----1111)))) **** ....5555ffff
  1743.                         ---- iiii////hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt )))) **** 44445555....ffff,,,, 0000,,,, 0000))));;;;
  1744.            ppppffffCCCChhhhaaaannnnVVVViiiieeeewwwwOOOOffffffffsssseeeettttssss((((cccchhhhaaaannnn,,,, xxxxyyyyzzzz,,,, hhhhpppprrrr))));;;;
  1745.            iiiiffff ((((iiii ======== 0000))))
  1746.                mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn ==== cccchhhhaaaannnn;;;;
  1747.            eeeellllsssseeee
  1748.                ppppffffAAAAttttttttaaaacccchhhhCCCChhhhaaaannnn((((mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn,,,, cccchhhhaaaannnn))));;;;
  1749.        }}}}
  1750.  
  1751.        The remainder of the code should follow a typical multipipe
  1752.        application.
  1753.  
  1754.        There are certain restrictions on usage of _p_f_P_i_p_es,
  1755.        _p_f_P_i_p_e_W_i_n_d_o_ws and _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_ls when running in
  1756.        hyperpipe mode. All actions (with the exception of graphics
  1757.        pipe specific controls, e.g., pfPWinFBConfigAttrs() and
  1758.        pfPWinFBConfigId) should occur on those objects associated
  1759.        with the master _p_f_P_i_p_e.  In those instances where pipe
  1760.        specific attributes need modification, the appropriate
  1761.        pfPipeWindow or pfPipeVideoChannel can be obtained using the
  1762.        indexed pfGetPipePWin and pfGetPWinPVChan functions.  The
  1763.        index should equal the index of the associated master object
  1764.        on the master pipe.
  1765.  
  1766.        There is a limitation in that changes to _p_f_P_i_p_e_W_i_n_d_o_ws
  1767.        affected by the draw process will not be propagated to other
  1768.        _p_f_P_i_p_e_W_i_n_d_o_ws in the hyperpipe. Also, statistics drawn by
  1769.        the _p_f_F_r_a_m_e_S_t_a_t_s will reflect only the times for a
  1770.        particular draw process and not the entire hyperpipe. These
  1771.        problems may be removed in a later release.
  1772.  
  1773.  
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.                                   - 28 -
  1787.  
  1788.  
  1789.  
  1790.        6.16  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3
  1791.  
  1792.        6.16.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3
  1793.  
  1794.           +o Performer 2.2 always used the channel frustum for
  1795.             culling when PFCULL_GSET was set, even if a custom cull
  1796.             frustum polytope was defined.  This has been fixed.
  1797.             (SCR 635693)
  1798.  
  1799.           +o Attempting to delete a cliptexture could cause a core
  1800.             dump.  Cliptexture deletion is not supported, so a
  1801.             DEBUG-level warning is now emitted.  (SCR 594276)
  1802.  
  1803.           +o Fully transparent pfLPointStates could cause
  1804.             segmentation violations in Performer 2.2.  This has
  1805.             been fixed.  (SCR 614274)
  1806.  
  1807.           +o The FLT loader printed assertion failures such as the
  1808.             following:
  1809.  
  1810.                +o pfdConverterMode_flt: user data slot cannot be set
  1811.                  to 1
  1812.  
  1813.                +o pfdConverterMode_flt: private user data slot
  1814.                  cannot be set to 2
  1815.  
  1816.             The cause of these problems has been fixed.  (SCR
  1817.             624177)
  1818.  
  1819.           +o pfdFindConverterDSO was unable to locate the 3ds file
  1820.             loader. This was the result of conflicting IL and IFL
  1821.             versions and has been fixed.  (SCR 625838)
  1822.  
  1823.           +o The warning "pfTexture::compare(): pfClipTexture is not
  1824.             a pfTexture" was emitted when comparing a pfGeoState
  1825.             with cliptexture to one with a regular texture.  This
  1826.             has been fixed.  (SCR 626001)
  1827.  
  1828.           +o Picking with orthographic viewing frusta returned
  1829.             incorrect hit points.  This has been fixed.  (SCR
  1830.             601650)
  1831.  
  1832.           +o Color fields in pfGeoSets were not being handled
  1833.             correctly during the print traversal.  This has been
  1834.             fixed.  (SCR 621124)
  1835.  
  1836.           +o pfuTravCalcBBox in trav.c did not calculate the
  1837.             bounding box for pfBillboard nodes.  It now does.  (SCR
  1838.             632225)
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.  
  1852.                                   - 29 -
  1853.  
  1854.  
  1855.  
  1856.        6.17  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2
  1857.  
  1858.        6.17.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2
  1859.  
  1860.           +o _p_f_B_i_l_l_b_o_a_r_d_s were always using Z axis (Bug #591154)
  1861.  
  1862.           +o _p_f_P_i_p_e_W_i_n_d_o_w _r_e_s_i_z_e _w_i_t_h _f_o_r_k_e_d _c_u_l_l caused per-frame
  1863.             slow X communication. (Bug #611816)
  1864.  
  1865.           +o _p_f_T_e_x_t_u_r_e _w_i_t_h _T_e_x_L_O_D _s_e_t_t_i_n_g_s would leak memory. (Bug
  1866.             #600949)
  1867.  
  1868.           +o _p_f_U_n_r_e_f_D_e_l_e_t_e() would delete an object when its ref
  1869.             count was decremented to 65536.  This has been fixed,
  1870.             and the types of pfGetRef() and pfUnrefGetRef() have
  1871.             been changed from ushort to int. (Bug #603177)
  1872.  
  1873.           +o The _l_o_o_k_a_h_e_a_d directive was ignored in no-imagecache
  1874.             ._c_t _c_l_i_p _t_e_x_t_u_r_e _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s.  _N_O_T_E: since this
  1875.             is fixed, applications using .ct files containing a
  1876.             lookahead command may use much more memory, and may
  1877.             have to be re-tuned (or the lookahead command removed).
  1878.             (Bug #576096)
  1879.  
  1880.           +o The CSB loader has been updated to enable loading of
  1881.             files created by OpenGL Optimizer 1.2
  1882.  
  1883.           +o The FLT loader has been updated to version 15.4g (Bug
  1884.             #615990).  Several bugs have been fixed, including:
  1885.  
  1886.                +o A bug in revision R15.4fi where
  1887.                  pfuTexGenClipCenterNode was inserted as parent of
  1888.                  root node.  In such cases the clip texture was not
  1889.                  centered.
  1890.  
  1891.                +o A bug in revision R15.4fi where the loader's user
  1892.                  data slot was not initialized.  This caused core
  1893.                  dumps when certain run-time features were enabled
  1894.                  such as clip planes, behaviors, and adaptive light
  1895.                  points.
  1896.  
  1897.                +o _P_r_o_j_e_c_t_e_d _t_e_x_t_u_r_e_s behaved improperly when using
  1898.                  multiple channels or when lighting was off. (Bugs
  1899.                  #581332, #581334)
  1900.  
  1901.                +o _I_n_f _f_r_a_m_e _r_a_t_e _r_e_p_o_r_t_e_d _f_o_r _I_n_t_e_r_l_a_c_e_d _v_i_d_e_o
  1902.                  _f_o_r_m_a_t_s.  Now, the current swap rate will be
  1903.                  reported which for interlaced video formats might
  1904.                  be faster than the requested frame rate (ie.
  1905.                  60/30Hz).  (Bug #603567).
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911.  
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.                                   - 30 -
  1919.  
  1920.  
  1921.  
  1922.                +o _v_i_s_f_l_y _d_e_m_o was unable to start due to an
  1923.                  unresolvable symbol in the compat libraries,
  1924.                  pfuCalcNormalizedChanXY (Bug #600942)
  1925.  
  1926.                +o _B_a_d _L_i_g_h_t_i_n_g - the 2.0.6/2.1.4 compat libraries
  1927.                  had bad lighting characteristics; all lit models
  1928.                  were shaded grey  (Bug #598903)
  1929.  
  1930.                +o _p_f_d_F_i_n_d_C_o_n_v_e_r_t_e_r_D_S_O() in 2.0.6/2.1.4 was failing
  1931.                  due to a lookup problem in pfdLoadFile.  (Bug
  1932.                  #605958)
  1933.  
  1934.                +o _6_4_b_i_t _o_p_e_r_a_t_i_o_n _w_i_t_h _I_R_I_X _6._5 could fail with IRIS
  1935.                  Performer 2.0 and 2.1 libraries.  This is fixed in
  1936.                  the IRIS Performer libraries that were shipped
  1937.                  with IRIX 6.5 and also in the 2.0.7/2.1.5
  1938.                  libraries.
  1939.  
  1940.  
  1941.        6.18  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1
  1942.  
  1943.        6.18.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1
  1944.  
  1945.           +o _a_s_d_f_l_y _z_b_u_f_f_e_r _p_r_o_b_l_e_m_s _o_n _i_R due to a lose layer
  1946.             offset call in asdfly/terrain.c. (Bug #575993)
  1947.  
  1948.           +o _M_u_l_t_i_p_i_p_e _C_a_l_l_i_g_r_a_p_h_i_c_s supports 10 pipes instead of
  1949.             just 3.  (Bug #559773)
  1950.  
  1951.           +o _M_u_l_t_i_p_i_p_e _p_f_G_e_t_S_c_r_e_e_n() _r_e_t_u_r_n_i_n_g (-_1)_i_n _d_r_a_w _s_t_a_g_e
  1952.             _c_a_l_l_b_a_c_k _i_n_i_t..
  1953.  
  1954.           +o _O_p_e_n_W_o_r_l_d_s _V_R_M_L _2._0 (._w_r_l) _l_o_a_d_e_r failed for N32 and
  1955.             N64 due to default library search path
  1956.             (/usr/lib[32,64]. (Bug #575792)
  1957.  
  1958.           +o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _w_i_t_h _a_u_t_o_m_a_t_i_c _c_l_i_p_t_e_x_t_u_r_e
  1959.             _c_e_n_t_e_r_i_n_g could dump core if pfuInit() was not called
  1960.             by the application before pfConfig().  (Bug #575589)
  1961.  
  1962.           +o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _u_s_i_n_g _n_e_w _1_5._4 _f_e_a_t_u_r_e_s could
  1963.             dump core due to lack of initialization of user data
  1964.             slot used for behaviors and clip planes.  (Bug #575586)
  1965.  
  1966.           +o _X_s_g_i_v_c _V_i_d_e_o _C_h_a_n_n_e_l _0 had to exist or Performer would
  1967.             hang on startup.  This also caused hangs on OCTANE OCO
  1968.             (multi-channel operation).  (Bug #577815)
  1969.  
  1970.           +o _N_6_4 _V_i_d_e_o _c_h_a_n_n_e_l _o_p_e_r_a_t_i_o_n_s would dump core (Bug
  1971.             #575616).  To see this fix on IRIX 6.2 or IRIX 6.4,
  1972.             additional X and GL patches are required.
  1973.  
  1974.  
  1975.  
  1976.  
  1977.  
  1978.  
  1979.  
  1980.  
  1981.  
  1982.  
  1983.  
  1984.                                   - 31 -
  1985.  
  1986.  
  1987.  
  1988.           +o _I_n _O_c_t_a_n_e _O_C_O _m_o_d_e  _o_r _n_o _v_i_d_e_o _c_h_a_n_n_e_l  would result
  1989.             in no pfPipeWindow being opened. (Bug #577065).
  1990.  
  1991.           +o _D_V_R _s_h_o_w_i_n_g _n_o_i_s_e _o_n _b_o_t_t_o_m _l_i_n_e_s _o_f _v_i_d_e_o. (Bug
  1992.             #577976).
  1993.  
  1994.           +o _p_f_i_S_p_h_e_r_i_c _m_o_t_i_o_n _m_o_d_e_l _t_r_a_n_s_i_t_i_o_n (rail) tracking was
  1995.             too fast for really slow speeds (in the range of
  1996.             0.000001).  (Bug #583127).
  1997.  
  1998.  
  1999.        6.18.2  _P_r_o_b_l_e_m_s _f_i_x_e_d _i_n _2._0._6 _a_n_d _2._1._4 (_s_h_i_p_p_e_d _w_i_t_h
  2000.        _2._2._1)
  2001.  
  2002.           +o _p_f_u_C_o_n_f_i_g_M_C_O now properly initializes multiple channels
  2003.             on multiple pipes. (Bug #564062)
  2004.  
  2005.           +o _p_f_W_i_n_d_o_w::_g_e_t_F_B_C_o_n_f_i_g_A_t_t_r_s() was core dumping on
  2006.             pbuffers.  It will now return NULL for a pbuffer since
  2007.             the attribute arrays is for XVisuals and pbuffers
  2008.             require GLXFBConfigSGIXs which should be specified with
  2009.             pfWindow::setFBConfig(). (Bug #575989)
  2010.  
  2011.           +o _p_f_u_S_a_v_e_I_m_a_g_e _i_n _N_6_4 didn't work due to bad pointer
  2012.             types in libpfutil/snapwin.c. (Bug #575243)
  2013.  
  2014.           +o _N_6_4 _p_l_a_c_e_m_e_n_t _o_f _p_f_D_a_t_a_P_o_o_l_s could cause brk to run out
  2015.             of space for heap area. (Bug #575065)
  2016.  
  2017.  
  2018.        6.19  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2
  2019.  
  2020.        6.19.1  _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._0_._4__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._0_._5__a_n_d__2_._2
  2021.  
  2022.  
  2023.           +o _p_f_I_n_i_t_C_l_o_c_k in 250MHz IMPACT use not to be consistent.
  2024.  
  2025.           +o _P_i_c_k_i_n_g models with LOD unded DCS used to fail with
  2026.             large DCS translations (bug#455490)
  2027.  
  2028.           +o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
  2029.             texture.
  2030.  
  2031.           +o _p_f_B_o_x contains function has been fixed
  2032.  
  2033.           +o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
  2034.             dump if the application store double float in the
  2035.             datapool.
  2036.  
  2037.           +o Some _q_u_e_r_y feature request were missing, 2.0.5 is now
  2038.             at the same level as 2.2.
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.                                   - 32 -
  2051.  
  2052.  
  2053.  
  2054.           +o Assigning a Drawable without a visual used to cause the
  2055.             window not to open. (bug# 450891)
  2056.  
  2057.           +o Full screen had a window border when compiling for N64.
  2058.             (bug #542372)
  2059.  
  2060.           +o _p_b_u_f_f_e_r were not fully supported.
  2061.  
  2062.  
  2063.        6.19.2  _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._1_._2__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._1_._3__a_n_d__2_._2
  2064.  
  2065.  
  2066.           +o When the first video channel on a graphic pipeline was
  2067.             not active, _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_l was failing under forked
  2068.             DRAW multi-process.
  2069.  
  2070.           +o _A_S_D _T_e_r_r_a_i_n was not supporting dynamic paging. This
  2071.             fixed so ASD tiles can be dynamically paged in the
  2072.             DBASE prmcess.
  2073.  
  2074.           +o _A_S_D _T_e_r_r_a_i_n was not working on multipipe. This is fixed
  2075.             and ASD works fine with multiple pipes/channels. _a_s_d_f_l_y
  2076.             is fixed as well.
  2077.  
  2078.           +o _V_e_r_t_e_x _a_r_r_a_y_s used in a GL display list used to produce
  2079.             invalid normals.  This has been fixed in OpenGL with
  2080.             patch 1808 or later.
  2081.  
  2082.           +o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
  2083.             texture.
  2084.  
  2085.           +o _p_f_B_o_x contains function has been fixed
  2086.  
  2087.           +o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
  2088.             dump if the application store double float in the
  2089.             datapool.
  2090.  
  2091.           +o Full screen had a window border when compiling for N64.
  2092.             (bug #542372)
  2093.  
  2094.           +o Some _q_u_e_r_y feature request were missing, 2.1.3 is now
  2095.             at the same level as 2.2.
  2096.  
  2097.           +o _M_o_t_i_f decoration hints used not to work in 64 bits N64.
  2098.  
  2099.  
  2100.        6.19.3  _O_t_h_e_r__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._2
  2101.  
  2102.           +o _I_n_v_e_n_t_o_r loader used not to work N32/N64. (bug# 434322)
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.                                   - 33 -
  2117.  
  2118.  
  2119.  
  2120.           +o _G_a_n_g_S_w_a_p was not working at all for OpenGL. This is
  2121.             fixed in performer and in OpenGL after patch 1808.
  2122.  
  2123.           +o _p_e_r_f_l_y did not accept input from other screens than the
  2124.             master screen. (bug# 459186)
  2125.  
  2126.           +o _E_a_r_t_h_S_k_y used not to propagate the right fog values in
  2127.             sync to all screens in multipipe mode (bug# 437747)
  2128.  
  2129.           +o _s_h_a_d_o_w _t_e_x_t_u_r_e_s used not to be implemented for
  2130.             InfiniteReality/OpenGL.
  2131.  
  2132.           +o _p_f_c_o_n_v did core dump or go in infinite loop when
  2133.             converting some inventor files. (bug# 435232)
  2134.  
  2135.           +o _g_l_o_b_a_l _s_t_a_t_e used not to work properly and be in
  2136.             conflict with channel state (see option -q0 in perfly).
  2137.             (bug# 423829)
  2138.  
  2139.           +o _B_i_n_s used to have many problems. Bin number had to be
  2140.             in successive numbers (bug# 416557), bin Order had no
  2141.             effect at all, there was no way to draw the objects
  2142.             that are not falling into a bin (can be done in 2.2
  2143.             using pfDrawBin(-1)), there was no way to know which
  2144.             bins are in used (pfGetFreeBin() gets that information
  2145.             in 2.2). Note that 2.2 has a predefined #3 bin: the
  2146.             Light Point bin, and that this bin has a very special
  2147.             behavior and cannot be used for general purpose.
  2148.  
  2149.           +o _p_f_A_S_D used to only handle terrain with less than 65000
  2150.             vertices.
  2151.  
  2152.           +o _p_f_d_B_u_i_l_d_A_S_D used to have memory corruptions.
  2153.  
  2154.           +o _D_V_R used to produce garbage when used on a screen
  2155.             larger than 1280 pixels. Performer now prevent scaling
  2156.             in X direction as the hardware does not support it. It
  2157.             is not going to be fixed in OpenGL, it is a HW
  2158.             bandwidth limitation.
  2159.  
  2160.           +o _g_l_N_o_r_m_a_l_i_z_e was turned on by default, resulting in a
  2161.             minimal loss of performances. Now it is automatically
  2162.             turned on only when the current transformation matrix
  2163.             includes scaling, and turned off otherwise.
  2164.  
  2165.           +o Some _p_f_M_a_t_h routines were slower than system libmath
  2166.             routines that are now very optimized. The corresponding
  2167.             pfMath routines are replaced by a #define that calls
  2168.             system math routines directly.
  2169.  
  2170.  
  2171.  
  2172.  
  2173.  
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.                                   - 34 -
  2183.  
  2184.  
  2185.  
  2186.           +o _C_l_i_p_t_e_x_t_u_r_e have been upgraded to production standards
  2187.             for IRIS Performer 2.2. The core cliptexture
  2188.             functionality has been respecified to tighter
  2189.             tolerances, critical functionality such as load control
  2190.             and virtual cliptextures has been added, and additional
  2191.             API in libpfutil and libpfdu has been put in to make
  2192.             cliptextures easier to use in production applications.
  2193.  
  2194.           +o _p_e_r_f_l_y -_t now allows specification of visual ID for
  2195.             each pipe as a comma-separated list.
  2196.  
  2197.           +o _p_f_F_o_n_t._h in previous versions was missing some internal
  2198.             fields in the class declaration that would cause
  2199.             problems for C++ user code creating pfFont structures
  2200.             and the allocates structures would not be the proper
  2201.             size.
  2202.  
  2203.  
  2204.  
  2205.        6.19.4  _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._0_/_2_._1
  2206.        IRIS Performer 2.1 is an enhanced version of the IRIS
  2207.        Performer 2.0 release designed in conjunction with the Onyx
  2208.        InfiniteReality graphics hardware. It is, in essence,
  2209.        "Performer 2.0 with InfiniteReality extensions." Unlike IRIS
  2210.        Performer 2.1 that was only for InfiniteReality, the new
  2211.        IRIS Performer 2.2 is an enhanced version of IRIS Performer
  2212.        2.0/2.1 that runs on all SGI plateformes, enabling hardware
  2213.        specific features (DVR, ClipMapping) only when supported
  2214.        directly by the Graphic Subsystem.  IRIS Performer 2.2 has
  2215.        numerous improvements and new features over 2.0/2.1 such as
  2216.        pfFlux, pfb/pfi file formats, compute process for ASD,
  2217.        Calligraphic light support....  IRIS Performer 2.0 API is
  2218.        almost unchanged into 2.2, but it is not the case for 2.1 as
  2219.        the ClipMapping and ASD have had a lot of API changes.
  2220.  
  2221.  
  2222.        6.19.4.1  _C_l_i_p_T_e_x_t_u_r_e
  2223.  
  2224.        InfiniteReality supports very large textures through a
  2225.        virtual mipmapped texture scheme we call cliptexturing. Here
  2226.        is a preview of the basic concepts.
  2227.  
  2228.        Clip Textures provide a way use texture maps too large to
  2229.        hold in graphics texture memory. Until now, to use a large
  2230.        texture, you had to break it into tiles, bringing in the
  2231.        next texture as you approached a tile boundary.  This
  2232.        approach has numerous problems, including what to do about
  2233.        polygons that span texture tile boundaries, properly
  2234.        handling the changes in texture coordinates, doing
  2235.        MIPMapping without visual artifacts, etc.  Performer Clip
  2236.        Textures solve these problems. They allow you to seamlessly
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.                                   - 35 -
  2249.  
  2250.  
  2251.  
  2252.        use a very large texture, letting performer handle the
  2253.        loading issues.  Since it is one continuous texture, there
  2254.        are no problems with texture seams or changes in texture
  2255.        coordinates.
  2256.  
  2257.        A clip texture can be thought of as a very large mipmapped
  2258.        texture. The dimensions of level 0, the highest resolution
  2259.        level of the texture, is the clip texture's *virtual size*.
  2260.        For any given scene, only a subset of the entire clip
  2261.        texture is visible to the observer. pfClipTextures augment
  2262.        pfTextures by adding the notion of a center, a location in
  2263.        texel space that is close to the observer. As the center
  2264.        moves, the cliptexture must repeatedly applied, to update
  2265.        the texels in texture memory, so that contains the texels
  2266.        surrounding the current center.
  2267.  
  2268.        With the center properly updated, only a subset of the
  2269.        entire cliptexture need be loaded into texture memory at any
  2270.        given time. The visible region of this texture is called the
  2271.        *clip region*. The contents of this region are updated as
  2272.        the cliptexture center changes, always keeping the
  2273.        surrounding texel data available to the texturing hardware.
  2274.        The clip region can be visualized as a fixed width square
  2275.        column cutting through the mipmap levels. At the coarsest
  2276.        levels, where the MIPmap level becomes smaller than the clip
  2277.        region size, the cliptexture is a normal MIPmap pyramid. As
  2278.        the center moves on level 0, the column shears so that it
  2279.        surrounds the center, each level moving half as fast as the
  2280.        finer level above it.
  2281.  
  2282.        The texture itself is stored on disk and system memory as
  2283.        *tiles*. One or more tiles are stored as *texture tile
  2284.        files* on disk, and are brought into system memory as
  2285.        needed. A cache of these tiles, called the *memory region*
  2286.        is kept in system memory to reduce disk latency. A subset of
  2287.        the memory region texels, the *texture region* are
  2288.        downloaded to the graphics hardware texture memory.
  2289.  
  2290.        Each level of the clip texture larger than the clip size is
  2291.        contained in an level updated with the proper texel data,
  2292.        based on the center position at that level. The image cache
  2293.        must download texel data as tiles from the appropriate
  2294.        texture data files, keeping the mem region updated, and use
  2295.        texture subloads to update texel data from the texture
  2296.        region into proper area of hardware texture memory.  The
  2297.        clip texture itself is composed of image caches and image
  2298.        tiles. The image tiles describe the levels of the mipmap
  2299.        pyramid that are equal to or smaller than the clip region.
  2300.        It updates the clip texture center, and commands the image
  2301.        caches to reapply the texture memory as the center changes.
  2302.  
  2303.  
  2304.  
  2305.  
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311.  
  2312.  
  2313.  
  2314.                                   - 36 -
  2315.  
  2316.  
  2317.  
  2318.        The application can configure a clip texture by loading
  2319.        _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s, contains information about the texel
  2320.        data, cliptexture sizes, and texture file names and
  2321.        locations. A configured cliptexture can be used in the scene
  2322.        graph like a normal pfTexture. The application can attach
  2323.        mpcliptextures to cliptextures, and pipes to mpcliptextures
  2324.        automates the cliptexture apply process each frame, and
  2325.        allows cliptexture updates to be done in the application
  2326.        process. Every frame, the application updates the
  2327.        mpcliptexture _c_l_i_p_m_a_p _c_e_n_t_e_r. This can be automated by
  2328.        adding _c_e_n_t_e_r _n_o_d_e_s nodes to the scenegraph.
  2329.  
  2330.        Cliptextures have a load control feature called Dynamic
  2331.        Texture Resolution (DTR). This feature allows clipmaps to be
  2332.        roamed faster than the system bandwidth would normally
  2333.        allow. DTR accomplishes this by improving the order in which
  2334.        tiles are download into image caches, and selectively
  2335.        blurring the cliptexture and adjusting the effective
  2336.        clipsize in order to modulate the cliptextures bandwidth
  2337.        requirements. DTR is controlled through a mode bitmask,
  2338.        which is used to enable or disable various load control
  2339.        features, and by a set of parameters that can be adjusted by
  2340.        the application to tune load control performance.
  2341.  
  2342.        There is a special form of clipmaps, called virtual
  2343.        clipmaps, which can be used to exceed some of the
  2344.        limitations in maximum virtual size and number of levels
  2345.        inherent in the system hardware. Virtual clipmaps trade off
  2346.        larger possible cliptextures against increased complexity,
  2347.        and additional interactions between the cliptexture and the
  2348.        scenegraph. With virtual cliptextues, the cliptexture,
  2349.        itself a virtualization of a MIPmap, is itself virtualized.
  2350.        The physical cliptexture is roamed within a larger virtual
  2351.        cliptexture in three dimensions; s, t, and level of detail
  2352.        (LOD). This roaming is controlled by setting the center and
  2353.        adjusting the virtualLOD offset. The number of physical
  2354.        clipmap levels in use is controlled by adjusting the
  2355.        effective levels parameter. When many levels need to be
  2356.        accessed, the virtuallodoffset and other parameters can be
  2357.        dynamically modified as the scenegraph is traversed, trading
  2358.        off some performance for much wider range of available LOD
  2359.        levels.
  2360.  
  2361.        Man pages to see: pfClipTexture, pfQueue, pfImageTile
  2362.  
  2363.        Demos to check out:
  2364.  
  2365.                /usr/share/Performer/data/clipdata/hunter/run_hl
  2366.                /usr/share/Performer/data/clipdata/moffett/run_mof
  2367.  
  2368.  
  2369.  
  2370.  
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.                                   - 37 -
  2381.  
  2382.  
  2383.  
  2384.        Sample programs to check out:
  2385.  
  2386.                /usr/share/Performer/src/pguide/libpr/icache.c
  2387.                /usr/share/Performer/src/pguide/libpr/icache_mwin.c
  2388.                /usr/share/Performer/src/pguide/libpf/cliptex.c
  2389.                /usr/share/Performer/src/sample/C/perfly
  2390.  
  2391.        Utilities to use:
  2392.  
  2393.                /usr/share/Performer/src/libpfutil/cliptexture.c
  2394.                /usr/share/Performer/src/libpfutil/clipcenter.c
  2395.  
  2396.        ClipTexture Texture Data and Configuration Files:
  2397.  
  2398.                /usr/share/Performer/data/clipdata/hunter
  2399.                /usr/share/Performer/data/clipdata/moffett
  2400.                *.ic - image cache configuration files
  2401.                *.ct - cliptexture configuration files
  2402.  
  2403.  
  2404.  
  2405.        6.19.4.2  _V_i_r_t_u_a_l__c_l_i_p_t_e_x_t_u_r_e_s
  2406.  
  2407.        Virtual cliptextures of up to 1<<23 (8 million) texels on a
  2408.        side are supported by IRIS Performer 2.2.  This allows a
  2409.        real cliptextures (currently limited in size by the
  2410.        InfiniteReality hardware to at most 32Kx32K texels) to be
  2411.        embedded in a larger virtual clipmap of up to 8Mx8M texels.
  2412.  
  2413.        The application controls the position of the real
  2414.        cliptexture within the virtual cliptexture by updating the
  2415.        center and the _v_i_r_t_u_a_l _L_O_D _o_f_f_s_e_t. The offset adjusts the
  2416.        real cliptexture in the LOD direction.  The real cliptexture
  2417.        can only occupy positions that are valid subsets of the
  2418.        virtual cliptexture. The number of valid locations can be
  2419.        increased by using less _e_f_f_e_c_t_i_v_e _l_e_v_e_l_s The real
  2420.        cliptexture will automatically be centered around the
  2421.        current center of the virtual cliptexture, which the
  2422.        application sets on a per-frame basis (see above).
  2423.  
  2424.        Utilities are provided for intelligently selecting where to
  2425.        offset the real clipmap within the virtual clipmap each
  2426.        frame.  For details, see the source code for
  2427.        pfuCalcSizeFinestMipLOD in libpfutil, and play with the
  2428.        "Clip LOD Offset" slider in perfly when viewing a clip
  2429.        texture bigger than 32Kx32K.
  2430.  
  2431.  
  2432.        6.19.4.3  _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n
  2433.  
  2434.        A pfASD is a pfNode which can handle very large terrain
  2435.  
  2436.  
  2437.  
  2438.  
  2439.  
  2440.  
  2441.  
  2442.  
  2443.  
  2444.  
  2445.  
  2446.                                   - 38 -
  2447.  
  2448.  
  2449.  
  2450.        surfaces that are described as multiple LODs.  Active
  2451.        Surface Definition accuratedly describes different portions
  2452.        of the terrain using triangles from different LODs.  The
  2453.        multiple LODs have a coherent subdivision-surfaces-like
  2454.        relationship between the neighboring levels.  pfASD contains
  2455.        a small scene graph that is generated dynamically to reflect
  2456.        the current visible geometry being rendered.
  2457.  
  2458.        These routines implement the Active Surface Definition (ASD)
  2459.        feature.  ASD defines a hierarchical structure that
  2460.        organizes all the LODs of a terrain. At run-time, ASD
  2461.        traverses the structure, selecting triangles from different
  2462.        LODs to render the portion of the terrain that is within a
  2463.        volume of interest. Triangles are rendered either at their
  2464.        pre-stored locations, when they are in a particular LOD
  2465.        range, or at computed morphed locations, when they are
  2466.        within the morphing zone of a LOD range. There will be other
  2467.        ways to evaluate the terrain other than purely range based
  2468.        approach. The way to evaluate each vertex is the "evaluation
  2469.        function".  The evaluation function can be defined as a user
  2470.        call back function, when the default range based evaluation
  2471.        is not appropriate.
  2472.  
  2473.        An example of a user defined callback function can be found
  2474.        in
  2475.  
  2476.                /usr/share/Performer/src/sample/C/asdfly/eval_function.c
  2477.  
  2478.  
  2479.        pfASD has its own thread when user claimed multiprocessing
  2480.        mode, e.g.  PFMP_FORK_COMPUTE. Asychronizely, the evaluation
  2481.        of the structure is done in the thread and the created
  2482.        geometry (active mesh) are merged into the scenegraph
  2483.        internal to pfASD at pfFrame time.  pfASD enlarges the
  2484.        viewing frustum to accommodate the delay of evaluation.
  2485.  
  2486.        The cull of pfASD is handled together with the evaluation.
  2487.        In another word, the gsets that are generated by evaluation
  2488.        is the set of triangles that should be or soon to be
  2489.        visible.
  2490.  
  2491.        pfASD handles multichannel evaluation and ensures that
  2492.        neighboring channels will have consistently connected
  2493.        triangles.  A channel can also share the evaluated active
  2494.        mesh from another channel using pfChannel::ASDattach.  pfASD
  2495.        handles multipipe as well.
  2496.  
  2497.  
  2498.        6.19.4.4  _F_l_u_x__a_n_d__E_n_g_i_n_e
  2499.  
  2500.        A _p_f_F_l_u_x is a container for holding dynamic data.  It
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.                                   - 39 -
  2513.  
  2514.  
  2515.  
  2516.        contains multiple buffers of data each associated with a
  2517.        frame number.  This allows multiple processes to each have a
  2518.        copy of the data appropriate to the frame they are working
  2519.        on. A full pfGeoSet can be fluxed pfFlux should be used
  2520.        instead of pfCycleBuffer as they do not require a copy of
  2521.        the data to be done to synchronize the stages of the process
  2522.        pipeline.
  2523.  
  2524.        A _p_f_E_n_g_i_n_e is an object that controls the dynamic data in a
  2525.        pfFlux.  A pfEngine of type PFENG_MORPH associated with a
  2526.        pfFlux replaces a pfMorph node.
  2527.  
  2528.        see _p_f_F_l_u_x, _p_f_E_n_g_i_n_e, _p_f_F_S_C, _p_f_S_w_i_t_c_h and _p_f_L_O_D man pages.
  2529.  
  2530.  
  2531.        6.19.5  _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._1
  2532.  
  2533.  
  2534.        6.19.5.1  _C_l_i_p_M_a_p_p_i_n_g
  2535.  
  2536.        _p_f_I_m_a_g_e_C_a_c_h_e renamed some API calls (the corresponding gets
  2537.        are  not shown)
  2538.  
  2539.  
  2540.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeOOOOrrrriiiiggggiiiinnnn
  2541.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnOOOOrrrrgggg
  2542.  
  2543.  
  2544.  
  2545.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeSSSSiiiizzzzeeee
  2546.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  2547.  
  2548.  
  2549.  
  2550.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnOOOOrrrriiiiggggiiiinnnn
  2551.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnOOOOrrrrgggg
  2552.  
  2553.  
  2554.  
  2555.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  2556.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  2557.  
  2558.  
  2559.  
  2560.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDsssstttt
  2561.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxx
  2562.  
  2563.  
  2564.  
  2565.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDssssttttSSSSiiiizzzzeeee
  2566.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxSSSSiiiizzzzeeee
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578.                                   - 40 -
  2579.  
  2580.  
  2581.  
  2582.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVViiiirrrrttttuuuuaaaallllSSSSiiiizzzzeeee
  2583.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeIIIImmmmaaaaggggeeeeSSSSiiiizzzzeeee
  2584.  
  2585.  
  2586.  
  2587.                oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCeeeennnntttteeeerrrr
  2588.                oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMaaaaxxxxUUUUppppddddaaaatttteeeeSSSSiiiizzzzeeee
  2589.  
  2590.  
  2591.  
  2592.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccTTTTeeeexxxxRRRReeeeggggiiiioooonnnn
  2593.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccMMMMeeeemmmmRRRReeeeggggiiiioooonnnn
  2594.  
  2595.  
  2596.        _p_f_Q_u_e_u_e as new functionality
  2597.  
  2598.  
  2599.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttMMMMooooddddeeee
  2600.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttFFFFuuuunnnncccc
  2601.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  2602.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
  2603.                nnnneeeewwww:::: ppppffffGGGGeeeettttQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
  2604.  
  2605.  
  2606.        _p_f_I_m_a_g_e_C_a_c_h_e now use sorting queus Image cache configuration
  2607.        files have a version2.0 format. The parser will run with
  2608.        either format. The new format is a little more robust and
  2609.        easier to use. The parser also now calls separate pfutil
  2610.        functions that do the creation and configuration work. This
  2611.        will make it easier to create custom configuration routines.
  2612.  
  2613.        The configuration files now support relative pathnames.
  2614.        Cliptexture configuration files can now be created that
  2615.        don't need image cache configuration files.
  2616.  
  2617.  
  2618.        6.19.5.2  _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n
  2619.  
  2620.        _l_i_b_p_f_s _n_o _l_o_n_g_e_r _e_x_i_s_t_s. You should make sure you no longer
  2621.        link with it. pfTerrain no longer exists either.  All
  2622.        PFTERRAIN_ tokens have been renamed PFASD_.  Aligning object
  2623.        to pfASD uses pfFlux and pfEngine.
  2624.  
  2625.  
  2626.            ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ****ggggssss))))
  2627.  
  2628.        is now
  2629.  
  2630.  
  2631.            ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ********ggggssss,,,, iiiinnnntttt nnnnuuuummmm))))
  2632.  
  2633.  
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.  
  2643.  
  2644.                                   - 41 -
  2645.  
  2646.  
  2647.  
  2648.        It is important that when you port to this new api you use
  2649.        pfMalloc to allocate the array of pfGeoState pointers.
  2650.  
  2651.        So:
  2652.  
  2653.  
  2654.                ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((aaaassssdddd,,,, ggggssss))));;;;
  2655.  
  2656.        Should become:
  2657.  
  2658.  
  2659.                {{{{
  2660.                   ppppffffGGGGeeeeooooSSSSeeeetttt ********ggggssssssss;;;;
  2661.                   ggggssssssss ==== ((((ppppffffGGGGeeeeooooSSSSeeeetttt ********))))ppppffffMMMMaaaalllllllloooocccc((((ssssiiiizzzzeeeeooooffff((((ppppffffGGGGeeeeooooSSSSeeeetttt********))))****1111,,,,
  2662.                                ppppffffGGGGeeeettttSSSShhhhaaaarrrreeeeddddAAAArrrreeeennnnaaaa(((())))))));;;;
  2663.                   ggggssssssss[[[[0000]]]] ==== ggggssss;;;;
  2664.                   ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((aaaassssdddd,,,, ggggssssssss,,,, 1111))));;;;
  2665.                }}}}
  2666.  
  2667.        PFTERRAIN constants have become PFASD constants pfs prefix
  2668.        has become pfASD pfsFace data structure has become pfASDFace
  2669.        and the field names have been changed to properly reflect
  2670.        the functionality.
  2671.  
  2672.        A current version of the Muligen loader is supplied to
  2673.        handle these changes
  2674.  
  2675.        New sample programs including examples of aligning features
  2676.        and moving objects to ASD geometry.
  2677.  
  2678.                /usr/share/Performer/src/pguide/libpf/C/ASD_align.c
  2679.  
  2680.        New sample program that demonstrates the pfASD data
  2681.        structure
  2682.  
  2683.                /usr/share/Performer/src/pguide/libpf/C++/simpleASD.C
  2684.  
  2685.  
  2686.        pfASD can be paged in as simle areal blocks, as handled by
  2687.        Multigen CAT feature.
  2688.  
  2689.        pfASD also supports a multi-resolution paging scheme, very
  2690.        similar to clipmap paging. An example of the construction of
  2691.        pfASD from a set of uniform elevation data  can be found in
  2692.  
  2693.                /usr/share/Performer/src/lib/libpfdu/pfdBuildASD.c
  2694.  
  2695.        Inside the same file, you can find routines that constructs
  2696.        paging ASD tiles from a fully built ASD structure. Please
  2697.        notice that the builder is for demonstration purposes
  2698.        mainly. The algorithm used is not sophisticated enough to
  2699.  
  2700.  
  2701.  
  2702.  
  2703.  
  2704.  
  2705.  
  2706.  
  2707.  
  2708.  
  2709.  
  2710.                                   - 42 -
  2711.  
  2712.  
  2713.  
  2714.        provent terrain from visible morphing distortion during
  2715.        real-time fly through. The demo "yosemite" provided on 2.2
  2716.        demo CD is constructed using CAT feature in Multigen.
  2717.  
  2718.        Paging construction example can be found in
  2719.  
  2720.                /usr/share/Performer/src/pguide/libpf/C/buildarcinfo.c
  2721.                /usr/share/Performer/src/pguide/libpf/C/buildbw.c
  2722.                /usr/share/Performer/src/pguide/libpf/C/builddem.c
  2723.                /usr/share/Performer/src/pguide/libpf/C/builddted.c
  2724.  
  2725.        Executing the command, e.g.
  2726.  
  2727.                buildbw elevation.bw bw/tile bw/config bw/page
  2728.  
  2729.        will put a set of paging tiles under the directory bw, with
  2730.        prefix "tile" as their file names. Once you decide on how
  2731.        many extra tiles to page on each LOD based on LODRange as
  2732.        well as the paging delay, you MUST process the tiles one
  2733.        more time into a fast paging binary format before feeding it
  2734.        into a paging pfASD node.
  2735.  
  2736.        The second pass paging data construction can be found in
  2737.  
  2738.                /usr/share/Performer/src/pguide/libpf/C/convasd.c
  2739.  
  2740.        For example,
  2741.  
  2742.                convasd bw/config bw/page
  2743.  
  2744.        will process the tiles.  The final step is to hand all the
  2745.        attributes defined in the config file and page file to pfASD
  2746.        by calling
  2747.  
  2748.                pfdLoadConfig(config, page);
  2749.  
  2750.  
  2751.  
  2752.        6.19.5.3  _O_p_e_n_G_L__V_e_r_t_e_x__A_r_r_a_y_s
  2753.  
  2754.        The OpenGL _V_e_r_t_e_x_A_r_r_a_y extension is supported by IRIS
  2755.        Performer as an optimized way to send formatted data to the
  2756.        graphics pipeline, reducing the host interface.
  2757.  
  2758.        Vertex arrays use a new pfGSetAttr list, PFGS_PACKED_ATTRS,
  2759.        that includes a separate copy of the vertex attribute data
  2760.        packed into a single non-indexed array.  Your vertex
  2761.        coordinates may optionally be in this packed array.  A
  2762.        sample program that demonstrates the use of vertex arrays on
  2763.        pfGeoSets is in:
  2764.  
  2765.  
  2766.  
  2767.  
  2768.  
  2769.  
  2770.  
  2771.  
  2772.  
  2773.  
  2774.  
  2775.  
  2776.                                   - 43 -
  2777.  
  2778.  
  2779.  
  2780.                /usr/share/Performer/src/pguide/libpr/packedattrs.c
  2781.  
  2782.        Additionally, there is a utility traversal,
  2783.        pfuTravCreateVertArrays, that will traverse the scene graph
  2784.        and create vertex arrays for the pfGeoSets and optionally
  2785.        pfDelete the other redundant attribute arrays.  The utility
  2786.        routines used by this traversal to actually pack the
  2787.        pfGeoSet data is  pfuFillGSetVertArray().  This traversal
  2788.        can be invoked on the Perfly sample application with the -v
  2789.        # option where # is 1 or 2 to select one of two packed
  2790.        formats of with or without the vertices copied into the
  2791.        vertex array, respectively.
  2792.  
  2793.  
  2794.        6.19.5.4  _O_p_e_n_G_L__s_p_l_i_n_e__F_o_g
  2795.  
  2796.        InfiniteReality supports the specification of a fog function
  2797.        so Spline Fog support for OpenGL has been added to IRIS
  2798.        Performer and will be available on machines that support it.
  2799.  
  2800.  
  2801.        6.19.5.5  _T_F_a_n_s
  2802.  
  2803.        IRIS Performer 2.2 supports Triangle Fans in a pfGeoSets
  2804.        when using OpenGL
  2805.  
  2806.  
  2807.        6.19.5.6  _A_s_y_n_c_h_r_o_n_o_u_s__D_y_n_a_m_i_c__D_a_t_a
  2808.  
  2809.        IRIS Performer 2.2 supports truly asynchronous dynamic data
  2810.        with _p_f_F_l_u_x.  Data for geometry attributes in pfGeoSets and
  2811.        fields in various pfNodes can be computed in fully
  2812.        asynchronous processes and store in a pfFlux buffer.  pfFlux
  2813.        will manage the the hookup, data exclusion, and frame
  2814.        management accurate book-keeping.  pfFluxes can be
  2815.        explicitly driven by _p_f_E_n_g_i_n_e_s for defining the functions
  2816.        that generate the dynamic data.
  2817.  
  2818.        pfGeoSets themselves can be fluxed and fluxed pfGeoSets can
  2819.        be given to a pfGeode directly.
  2820.  
  2821.        pfEngines can be used to control the data in a flux. A
  2822.        complete graph of pfEngines and pfFlux can be done to
  2823.        control the dynamic behavior of a database. Both pfEngines
  2824.        and pfFluxes are stored in the performer binary file format
  2825.        (pfb), even external functions used by pfEngines can be
  2826.        registers into the pfb and the right DSO will automatically
  2827.        be loaded when the pfb file will be used in Performer.
  2828.  
  2829.  
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.                                   - 44 -
  2843.  
  2844.  
  2845.  
  2846.        6.19.5.7  _L_i_g_h_t__P_o_i_n_t
  2847.  
  2848.        A new light point process can be forked off and use a cpu to
  2849.        do the _p_f_L_P_o_i_n_t_S_t_a_t_e computation instead of taking time of
  2850.        the Draw Process.  The light point process is synchronous to
  2851.        the Draw process, and also support Calligraphic Light points
  2852.        when the Calligraphic Board and Projector are hooked to the
  2853.        system. To learn more about raster and calligraphic lights
  2854.        see the pfLPointState and _p_f_C_a_l_l_i_g_r_a_p_h_i_c man pages, as well
  2855.        as the pfChannel man pages to see how the light point
  2856.        process works.
  2857.  
  2858.  
  2859.        6.19.5.8  _N_e_w__l_o_a_d_e_r_s
  2860.  
  2861.           +o Loaders for creating pfASD structures from elevation
  2862.             data are now include in IRIS Performer 2.2
  2863.             _l_i_b_p_f_d_b/_l_i_b_p_f_d_e_m - This loader handles a variety of the
  2864.             USGS DEM elevation data products, including the common
  2865.             7.5 minute (1:24,000) and 1 degree (1:250,000) DEM
  2866.             files.  _l_i_b_p_f_d_b/_l_i_b_p_f_d_t_e_d - This loader handles DMA
  2867.             DTED Level 1 and 2 elevation data products.
  2868.             _l_i_b_p_f_d_b/_l_i_b_p_f_a_r_c_i_n_f_o - This loader handles elevation
  2869.             data files in the simple ARC/INFO ASCII GRID export
  2870.             format.  _l_i_b_p_f_d_b/_l_i_b_p_f_e_v_t - This loader reads data in
  2871.             the temporary ".evt" binary format.
  2872.             The loaders read the elevation data from the file and
  2873.             construct an appropriate pfASD node structure.  The
  2874.             origin coordinates of the created pfASD node will be
  2875.             set to the southwest corner, zero altitude point of the
  2876.             elevation data area.  The data will be oriented in the
  2877.             XY plane for elevation data specified in planar
  2878.             coordinates (such as UTM), or oriented properly on the
  2879.             earth ellipsoid for data specified in geodetic
  2880.             coordinates (Z-axis towards North Pole, X-axis defined
  2881.             by the intersection of the prime meridian and
  2882.             equatorial planes).  Use pfdBuildASD to indicate the
  2883.             levels of detail you wish to build.  That is the last
  2884.             parameter in pfdBuildASD().
  2885.  
  2886.             The function "libpfdu/pfdBuildASD()" can be used to
  2887.             construct pfASD structures for elevation data not
  2888.             handled by the above loaders.  There are support for
  2889.             building paging tiles in pfdBuildASD(). It is not
  2890.             turned on by default. Set the PAGING constant in
  2891.             pfdBuildASD.c to 1 if you want to experiment with
  2892.             paging pfASD tiles.
  2893.  
  2894.  
  2895.           +o A VRML 2.0 loader is included. This loader is a gift
  2896.             from DrAW Computing Associates and will successfully
  2897.  
  2898.  
  2899.  
  2900.  
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906.  
  2907.  
  2908.                                   - 45 -
  2909.  
  2910.  
  2911.  
  2912.             the geometry and texture of many VRML2.0 files. To have
  2913.             more VRML 2.0 support, such as Routes, JAVA,
  2914.             saveToVrml, html direct access from performer, or to
  2915.             report any problem with the VRML 2.0 loader you will
  2916.             have to contact them directly at info@openworlds.com.
  2917.             See the demos under openworlds in the Friend of
  2918.             Performer 2.2 CD.  Note that VRML 1.0 files are not
  2919.             supported by this loader. Previously the case, so you
  2920.             have either to convert your VRML1.0 files to VRML2.0,
  2921.             or to explicitly name your files .iv so the inventor
  2922.             loader will be used in place of the VRML 2.0 loader.
  2923.  
  2924.  
  2925.           +o A OpenGL Optimizer binary file loader (csb) is part of
  2926.             IRIS Performer 2.2 distribution. This allow exchange of
  2927.             files in between the two products as OpenGL Optimizer
  2928.             reads IRIS Performer binary files (pfb). Note that the
  2929.             pfb loader for Optimizer has a problem that changes all
  2930.             opaque polygons to fully transparent and vice-versa.
  2931.             This will be fixed, and a new pfb loader for OpenGL
  2932.             Optimizer will be available on the Web. (see section 4
  2933.             of release note)
  2934.  
  2935.  
  2936.  
  2937.        6.19.5.9  _C_o_p_l_a_n_a_r__g_e_o_m_e_t_r_y
  2938.  
  2939.        Layer and Decal geometry may now use the new OpenGL
  2940.        reference plane.  Reference planes may be specified on
  2941.        pfGeoSets, pfGeoStates, and in the global state.  See the
  2942.        pfGeoSet and pfDecal, and pfGeoState reference pages for
  2943.        more information.
  2944.  
  2945.  
  2946.        6.19.5.10  _T_e_x_t_u_r_e__m_a_t_r_i_c_e_s
  2947.        Texture matrices may now be specified on pfGeoStates.  See
  2948.        the pfGeoState reference page for more information.
  2949.  
  2950.  
  2951.        6.19.5.11  _T_r_a_v_e_r_s_a_l_s
  2952.        libpfutil traversal, pfuTravCompileDList, traversal for
  2953.        traversing an entire scene graph and creating display lists
  2954.        for all pfGeoSets.  This is to be used in combination with
  2955.        pfuTravDListDraw and is useful for compiling and pre-
  2956.        downloading display lists on InfiniteReality.
  2957.  
  2958.  
  2959.        6.19.5.12  _V_i_d_e_o__t_e_x_t_u_r_i_n_g
  2960.  
  2961.        There is one main sample program for video texturing:
  2962.  
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969.  
  2970.  
  2971.  
  2972.  
  2973.  
  2974.                                   - 46 -
  2975.  
  2976.  
  2977.  
  2978.           /usr/share/Performer/src/pguide/libpf/C/movietex.c
  2979.  
  2980.        a multiprocessing example.  Note that all video
  2981.        initialization, including the creation of video library
  2982.        resources, is done in the draw process, as required by the
  2983.        video library. The program has #define switches for
  2984.        compilation on IRIX 6.2 or IRIX 6.5 and supports DIVO,
  2985.        Sirius, OCTANE, and O2 video options.  Movitex.c uses
  2986.        features added in Performer 2.2: special pfTexture LOAD
  2987.        source parameters for specifying dmedia buffers or the video
  2988.        library server, path and drain, as well as the texture
  2989.        matrix that can be specified on a pfGeoState with the
  2990.        PFSTATE_TEXMAT attribute for transforming texture
  2991.        coordinates int the proper area of a texture receiving video
  2992.        input.
  2993.  
  2994.        An old Sirius example has been retained in
  2995.        /usr/share/Performer/src/pguide/libpr/C/siriusvidtex.c.
  2996.  
  2997.  
  2998.        6.19.5.13  _T_e_x_t_u_r_e__L_O_D__o_b_j_e_c_t
  2999.  
  3000.        New pfTexLOD object for controlling LOD of textures.
  3001.        pfTexLOD is a new state attribute used to control the use of
  3002.        levels of detail of a pfTexture.  The levels of detail
  3003.        accessed can be limited by setting the LOD range and the
  3004.        computation of the current LOD value can be biased.  These
  3005.        controls are useful in conjunction with dynamic texture
  3006.        loading where the accessed levels can be limited to the
  3007.        valid levels and for artificially blurring or sharpening a
  3008.        texture.
  3009.  
  3010.  
  3011.        6.19.5.14  _N_e_w__f_a_s_t__i_m_a_g_e__f_i_l_e__f_o_r_m_a_t
  3012.  
  3013.        There is now the pfi fast image file loader to complement
  3014.        pfb.  pfi files are hardware-ready fast loading image files
  3015.        that may contain MIPmaps for textures and multiple complete
  3016.        textures.
  3017.  
  3018.        /usr/share/Performer/src/sample/pfconv.c
  3019.  
  3020.        can convert a database to use pfi files for its textures. In
  3021.        addition, there is a
  3022.  
  3023.        /usr/share/Performer/src/sample/pficonv.c
  3024.  
  3025.        for converting .rgb files to pfi files and generating
  3026.        MIPmaps.  Look at the data/town/town_ogl_pfi.pfb database.
  3027.  
  3028.  
  3029.  
  3030.  
  3031.  
  3032.  
  3033.  
  3034.  
  3035.  
  3036.  
  3037.  
  3038.  
  3039.  
  3040.                                   - 47 -
  3041.  
  3042.  
  3043.  
  3044.        6.19.5.15  _p_f_C_h_a_n_n_e_l
  3045.        Here are the additional C++ member functions added in
  3046.        Performer 2.2 to those already provided in IRIS Performer
  3047.        2.1 for the pfChannel class. Each C++ function has a
  3048.        corresponding C function, and all are fully described in the
  3049.        IRIS Performer 2.2 C and C++ Reference Pages.
  3050.  
  3051.  
  3052.            ggggeeeettttFFFFrrrraaaammmmeeeePPPPVVVVCCCChhhhaaaannnn
  3053.            sssseeeettttOOOOuuuuttttppppuuuuttttVVVViiiieeeewwwwppppoooorrrrtttt
  3054.            sssseeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
  3055.            ggggeeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
  3056.            sssseeeettttCCCCaaaalllllllliiiigggg
  3057.            ggggeeeettttCCCCaaaalllllllliiiigggg
  3058.            ggggeeeettttCCCCuuuurrrrCCCCaaaalllllllliiiigggg
  3059.            ggggeeeettttFFFFrrrreeeeeeeeBBBBiiiinnnn
  3060.            AAAASSSSDDDDAAAAttttttttaaaacccchhhh
  3061.            AAAASSSSDDDDddddeeeettttaaaacccchhhh
  3062.  
  3063.        6.19.5.16  _p_f_D_i_s_p_L_i_s_t
  3064.  
  3065.        This is the additional C++ member function added in
  3066.        Performer 2.2 to those already provided in IRIS Performer
  3067.        2.1 for the pfDispList class. This function allows the
  3068.        contents of one IRIS Performer pfDispList to be appended to
  3069.        a second pfDispList, supporting the merge of independent
  3070.        pfDispLists.  The _p_f_D_i_s_p_L_i_s_t::_a_p_p_e_n_d C++ function has a
  3071.        corresponding C function (_p_f_A_p_p_e_n_d_D_L_i_s_t), and both are fully
  3072.        described in the IRIS Performer 2.2 C and C++ Reference
  3073.        Pages.
  3074.  
  3075.  
  3076.            ggggeeeettttGGGGLLLLHHHHaaaannnnddddlllleeee
  3077.            sssseeeettttMMMMooooddddeeee
  3078.            ccccoooommmmppppiiiilllleeee
  3079.            pppprrrreeeepppprrrroooocccceeeessssssss
  3080.  
  3081.        6.19.5.17  _p_f_Q_u_e_u_e
  3082.  
  3083.        Here are the additional C++ member functions added in
  3084.        Performer 2.2 to those already provided in IRIS Performer
  3085.        2.1 for the pfQueue class.  These new functions add support
  3086.        for having a sort process that will sort the items in the
  3087.        queue.  Each C++ function has a corresponding C function,
  3088.        and all are fully described in the IRIS Performer 2.2 C and
  3089.        C++ Reference Pages.
  3090.  
  3091.  
  3092.            ggggeeeettttEEEElllleeeemmmmeeeennnnttttSSSSiiiizzzzeeee
  3093.            sssseeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
  3094.            ggggeeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
  3095.  
  3096.  
  3097.  
  3098.  
  3099.  
  3100.  
  3101.  
  3102.  
  3103.  
  3104.  
  3105.  
  3106.                                   - 48 -
  3107.  
  3108.  
  3109.  
  3110.            ggggeeeettttSSSSoooorrrrttttMMMMooooddddeeee
  3111.            sssseeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  3112.            ggggeeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  3113.            ggggeeeettttOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
  3114.            ggggeeeettttSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
  3115.            iiiinnnnsssseeeerrrrttttFFFFrrrroooonnnntttt
  3116.            aaaatttttttteeeemmmmppppttttRRRReeeemmmmoooovvvveeee
  3117.            ssssiiiiggggnnnnaaaallllAAAAllllllllSSSSeeeerrrrvvvviiiicccceeeePPPPrrrrooooccccssss
  3118.            nnnnoooottttiiiiffffyyyySSSSoooorrrrttttPPPPrrrroooocccc
  3119.  
  3120.        6.19.5.18  _p_f_I_m_a_g_e_T_i_l_e
  3121.  
  3122.        Here are the additional C++ member functions added in
  3123.        Performer 2.2 to those already provided in IRIS Performer
  3124.        2.1 for the pfQueue class.  Each C++ function has a
  3125.        corresponding C function, and all are fully described in the
  3126.        IRIS Performer 2.2 C and C++ Reference Pages.
  3127.  
  3128.  
  3129.           sssseeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
  3130.           ggggeeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
  3131.           iiiissssLLLLooooaaaaddddiiiinnnngggg
  3132.           sssseeeettttPPPPrrrriiiioooorrrriiiittttyyyy
  3133.           ggggeeeettttPPPPrrrriiiioooorrrriiiittttyyyy
  3134.           sssseeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
  3135.           ggggeeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
  3136.           sssseeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
  3137.           ggggeeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
  3138.           sssseeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
  3139.           ggggeeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
  3140.           RRRReeeeaaaaddddDDDDiiiirrrreeeecccctttt
  3141.           RRRReeeeaaaaddddNNNNoooorrrrmmmmaaaallll
  3142.  
  3143.        6.19.5.19  _p_f_C_l_i_p_T_e_x_t_u_r_e
  3144.  
  3145.        Here are the additional C++ member functions added in
  3146.        Performer 2.2 to those already provided in IRIS Performer
  3147.        2.1 for the pfQueue class.  New functions deal with DTR,
  3148.        which is a tight control on how much time you want to
  3149.        allocate in the DrawProcess to dynamically load the texture
  3150.        versus drawing polygons, and control of Virtual (bigger)
  3151.        clip textures.  Each C++ function has a corresponding C
  3152.        function, and all are fully described in the IRIS Performer
  3153.        2.2 C and C++ Reference Pages.
  3154.  
  3155.  
  3156.            ggggeeeettttCCCCuuuurrrrCCCCeeeennnntttteeeerrrr
  3157.            sssseeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
  3158.            ggggeeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
  3159.            sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
  3160.            ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
  3161.  
  3162.  
  3163.  
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169.  
  3170.  
  3171.  
  3172.                                   - 49 -
  3173.  
  3174.  
  3175.  
  3176.            sssseeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
  3177.            ggggeeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
  3178.            ggggeeeettttOOOOffffffffsssseeeetttt
  3179.            sssseeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
  3180.            ggggeeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
  3181.            sssseeeettttMMMMaaaasssstttteeeerrrr
  3182.            ggggeeeettttMMMMaaaasssstttteeeerrrr
  3183.            ggggeeeettttSSSSllllaaaavvvveeee
  3184.            sssseeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
  3185.            ggggeeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
  3186.            sssseeeettttDDDDTTTTRRRRMMMMooooddddeeee
  3187.            ggggeeeettttDDDDTTTTRRRRMMMMooooddddeeee
  3188.            ggggeeeettttMMMMiiiinnnnDDDDTTTTRRRRLLLLOOOODDDD
  3189.            ggggeeeettttDDDDTTTTRRRRFFFFaaaaddddeeeeCCCCoooouuuunnnntttt
  3190.            sssseeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
  3191.            ggggeeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
  3192.            sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
  3193.            ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
  3194.            sssseeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
  3195.            ggggeeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
  3196.            sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
  3197.            ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
  3198.            sssseeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
  3199.            ggggeeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
  3200.            ggggeeeettttCCCCuuuurrrrLLLLOOOODDDDRRRRaaaannnnggggeeee
  3201.            sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassss
  3202.            ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassss
  3203.            ggggeeeettttCCCCiiiirrrrLLLLOOOODDDDBBBBiiiiaaaassss
  3204.            aaaappppppppllllyyyyMMMMeeeemmmmRRRReeeegggg
  3205.            aaaappppppppllllyyyyTTTTeeeexxxxRRRReeeegggg
  3206.            uuuuppppddddaaaatttteeeeMMMMeeeemmmmTTTTeeeegggg
  3207.            uuuuppppddddaaaatttteeeeTTTTeeeexxxxRRRReeeegggg
  3208.            uuuuppppddddaaaatttteeee
  3209.            iiiinnnnvvvvaaaalllliiiiddddaaaatttteeee
  3210.            aaaappppppppllllyyyyVVVViiiirrrrttttuuuuaaaallllPPPPaaaarrrraaaammmmssss
  3211.            aaaappppppppllllyyyyCCCCeeeennnntttteeeerrrr
  3212.            iiiissssVVVViiiirrrrttttuuuuaaaallll
  3213.  
  3214.        6.20  _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _I_R_I_S _P_e_r_f_o_r_m_e_r _2._0 _a_n_d _p_r_e_v_i_o_u_s
  3215.              _r_e_l_e_a_s_e_s
  3216.  
  3217.        This section elucidates the changes and enhancements between
  3218.        the prior IRIS Performer 2.0 release and the even older IRIS
  3219.        Performer 1.2 release. Since all the 2.0 features are
  3220.        included in 2.2 this concerns porting from 1.2 to 2.2 as
  3221.        well.
  3222.  
  3223.        If you are new to IRIS Performer or if you have already
  3224.        converted your applications to the more recent 2.0 release
  3225.        you can skip this section, since the information contained
  3226.        here is provided merely to ease porting efforts for older
  3227.  
  3228.  
  3229.  
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.                                   - 50 -
  3239.  
  3240.  
  3241.  
  3242.        applications. These features are also described in the the
  3243.        IRIS Performer Programming Guide.
  3244.  
  3245.  
  3246.        6.20.1  _N_e_w__F_e_a_t_u_r_e_s
  3247.  
  3248.        6.20.1.1  _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L
  3249.        Performer 2.0 includes separate sets of libraries for
  3250.        supporting IRIS GL or OpenGL interfaces. These libraries
  3251.        have GL-dependent suffixes to indicate their type: IRIS
  3252.        GL=_igl and OpenGL=_ogl
  3253.  
  3254.            IIIIRRRRIIIISSSS GGGGLLLL:::: lllliiiibbbbppppffff____iiiiggggllll....ssssoooo
  3255.  
  3256.            OOOOppppeeeennnnGGGGLLLL:::: lllliiiibbbbppppffff____ooooggggllll....ssssoooo
  3257.  
  3258.        Porting an IRIS Performer application from IRIS GL to OpenGL
  3259.        should require very little work.  There are a couple of
  3260.        isolated routine changes (see API changes below).  The main
  3261.        work will be in porting an application IRIS GL code in user
  3262.        draw callbacks and in porting the windowing and event
  3263.        handling to X.  For porting windowing code, pfWindows and
  3264.        pfPipeWindows (libpr and libpf, respectively) provide a GL
  3265.        independent windowing environment.  Libpfutil provides GL-
  3266.        input handling utilities for libpf applications using
  3267.        pfPipeWindows (pfuInitInput()).  The sample programs
  3268.        installed in
  3269.  
  3270.            ////uuuussssrrrr////sssshhhhaaaarrrreeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ssssrrrrcccc////ppppgggguuuuiiiiddddeeee////{{{{lllliiiibbbbpppprrrr,,,,lllliiiibbbbppppffff}}}}////pppprrrrooooggggssss
  3271.  
  3272.        also demonstrate comparative X vs GL input handling.
  3273.  
  3274.        When compiling for IRIS GL, use '-DIRISGL' on the command
  3275.        line to include the IRIS GL versions of the Performer header
  3276.        files.
  3277.  
  3278.  
  3279.        6.20.1.2  _6_4_-_b_i_t__a_d_d_r_e_s_s__s_p_a_c_e__s_u_p_p_o_r_t
  3280.  
  3281.        6.20.1.3  _P_e_r_f_o_r_m_e_r__E_n_v_i_r_o_n_m_e_n_t__V_a_r_i_a_b_l_e_s__a_n_d__D_S_O_s
  3282.        Performer now robustly supports the notion of separate run-
  3283.        time file loaders as DSO's (Dynamic Shared Objects).  Thus,
  3284.        the generic utility method for opening a file now differs
  3285.        considerably - the extension of the filename is used to
  3286.        determine the name of shared object to load as well as the
  3287.        function within that shared library to call.  Two new
  3288.        environment variables exist to help locate these dynamic
  3289.        shared object libraries at run-time:
  3290.  
  3291.           +o PFLD_LIBRARY_PATH Specifies a colon separated list of
  3292.             directories where Performer should look for dynamic
  3293.  
  3294.  
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301.  
  3302.  
  3303.  
  3304.                                   - 51 -
  3305.  
  3306.  
  3307.  
  3308.             objects...
  3309.  
  3310.           +o PFHOME Specifies the root Performer directory (the root
  3311.             used to install Performer).  This is used such that
  3312.             various code in the libraries can look relative to this
  3313.             top level such as $PFHOME/usr/lib/libpfdb might be a
  3314.             location where dso's would live.  In this way a
  3315.             consistent tree structure might be maintained
  3316.             regardless of Performers PFHOME directory.  (This is
  3317.             useful when using Performer installed on another
  3318.             automounted machine for instance - setenv PFHOME
  3319.             /hosts/remote_machine/)
  3320.  
  3321.  
  3322.        6.20.1.4  _C_+_+__A_P_I
  3323.        When compiling programs using Performer's C++ API, you need
  3324.        to directly include the class header files from
  3325.  
  3326.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////pppprrrr
  3327.  
  3328.        and
  3329.  
  3330.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffff....
  3331.  
  3332.        6.20.1.5  _C_o_m_p_i_l_i_n_g _P_e_r_f_o_r_m_e_r _1._2 _C++ _a_p_p_l_i_c_a_t_i_o_n_s _w_i_t_h
  3333.        _P_e_r_f_o_r_m_e_r _2._0   With Performer 2.0, compiling a Performer
  3334.        application with the C++ compiler enables the use of C++
  3335.        classes for Performer types.  Some of these Performer types
  3336.        (pfMatrix, pfVec2, pfVec3, pfVec4, pfQuat) are typedefed
  3337.        arrays when compiling with C and classes when compiling with
  3338.        C++.  Because typedefed arrays and classes differ in their
  3339.        usage, Performer applications written C++ using Performer
  3340.        1.2's C API may not compile under C++ unless Performer is
  3341.        told to revert to C types when compiling under C++.
  3342.  
  3343.        If you wish to compile existing C++ code using Performer C
  3344.        types add the line
  3345.  
  3346.            ''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCCPPPPLLLLUUUUSSSSPPPPLLLLUUUUSSSS____AAAAPPPPIIII 0000''''
  3347.  
  3348.        before including any Performer header files.  Note that the
  3349.        use of C types precludes the use of Performer's C++ API.
  3350.  
  3351.  
  3352.        6.20.1.6  _M_i_x_i_n_g__C_+_+__A_P_I__a_n_d__C__A_P_I__i_n__a__S_i_n_g_l_e__A_p_p_l_i_c_a_t_i_o_n
  3353.  
  3354.        Normally, when compiling under C++, the C API routines
  3355.        corresponding to member functions on a class are not exposed
  3356.        in the header files.  Applications wishing to taste the
  3357.        combined smorgasbord of both APIs should add the line
  3358.  
  3359.  
  3360.  
  3361.  
  3362.  
  3363.  
  3364.  
  3365.  
  3366.  
  3367.  
  3368.  
  3369.  
  3370.                                   - 52 -
  3371.  
  3372.  
  3373.  
  3374.            ''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCC____AAAAPPPPIIII 1111
  3375.  
  3376.        before including any Performer header files.
  3377.  
  3378.  
  3379.        6.20.2  _L_I_B_P_R__E_n_h_a_n_c_e_m_e_n_t_s
  3380.  
  3381.        6.20.2.1  _p_f_G_e_o_S_e_t
  3382.        PFGS_POLYS for N-sided, convex polygons. Specify the number
  3383.        of sides of each polygon with pfGSetPrimLengths().
  3384.  
  3385.        pfGSetPassFilter() sets a filter which allows only specific
  3386.        pfGeoSets to be drawn, e.g., a
  3387.  
  3388.            PPPPFFFFGGGGSSSS____NNNNOOOONNNNTTTTEEEEXXXX____GGGGSSSSEEEETTTT |||| PPPPFFFFGGGGSSSS____EEEEMMMMIIIISSSSSSSSIIIIVVVVEEEE____GGGGSSSSEEEETTTT
  3389.  
  3390.        filter will draw only non-textured, emissive pfGeoSets.
  3391.  
  3392.        pfGetGSetAttrRange() returns the number of attributes (e.g.,
  3393.        coordinates) accessed by non-indexed a pfGeoSet and the
  3394.        maximum range of indexes if the pfGeoSet is indexed.
  3395.  
  3396.        pfGeoSets can now index their pfGeoStates through a global
  3397.        table set by pfApplyGStateTable(). pfGSetGStateIndex() sets
  3398.        the value which is used to index the global table. Indexed
  3399.        pfGeoStates in conjunction with different pfGeoState tables
  3400.        allow drastically different appearances of a single database
  3401.        without duplicating geometry or the scene graph.  For
  3402.        example, a visual and infrared version of a database is
  3403.        easily supported with 2 different pfGeoState tables.
  3404.  
  3405.        pfGeoSets now accept pfCycleBuffer* as attribute lists to
  3406.        support dynamic attribute changes in a pipelined,
  3407.        multiprocessing environment.  pfCycleBuffers automatically
  3408.        manage multiple data buffers to avoid data collisions and
  3409.        ensure frame-accurate behavior of attribute changes.  This
  3410.        greatly simplifies modification of coordinates for
  3411.        sophisticated facial and skeletal animation, geometrically
  3412.        morphed level-of-detail, and special effects such as
  3413.        explosions.  Note that pfCycleBuffer nodes are obsolete with
  3414.        IRIS Performer 2.2 and that pfFlux should be used instead of
  3415.        pfCycleBuffer.
  3416.  
  3417.  
  3418.        6.20.2.2  _p_f_G_e_o_S_t_a_t_e
  3419.        pfGStateFuncs() allow pre and post callbacks on a per-
  3420.        pfGeoState basis.  The pre callback is invoked after the GL
  3421.        has been configured with the pfGeoState's state and the post
  3422.        callback is lazily invoked by the next pfGeoState
  3423.        application so the pre/post callbacks nicely bracket
  3424.        pfDrawGSet().
  3425.  
  3426.  
  3427.  
  3428.  
  3429.  
  3430.  
  3431.  
  3432.  
  3433.  
  3434.  
  3435.  
  3436.                                   - 53 -
  3437.  
  3438.  
  3439.  
  3440.        pfGStateVal() is added for floating point values and now
  3441.        accepts PFSTATE_ALPHAREF.
  3442.  
  3443.        pfGeoSets can now index pfGeoStates (pfGSetGStateIndex())
  3444.        through pfGeoState global tables (pfApplyGStateTable()) or
  3445.        pfGeoState tables assigned to a pfChannel
  3446.        (pfChanGStateTable()) .
  3447.  
  3448.  
  3449.        6.20.2.3  _p_f_F_o_g
  3450.        pfGetFogDensity returns the density of a pfFog at a given
  3451.        range.
  3452.  
  3453.  
  3454.        6.20.2.4  _p_f_L_P_o_i_n_t_S_t_a_t_e
  3455.        A new PFSTATE attribute, pfLPointState causes pfGeoSets of
  3456.        type PFGS_POINTS to be rendered as "light points", e.g.,
  3457.        runway lights, stars. Light points have perspective size
  3458.        based on range and many other features. This is a major
  3459.        enhancement and is discussed in great detail in the
  3460.        pfLPointState man page.
  3461.  
  3462.  
  3463.        6.20.2.5  _p_f_S_p_r_i_t_e
  3464.        A new kind of transform, pfSprite automatically rotates
  3465.        pfGeoSets and plain GL geometry to face the viewer.
  3466.        Different rotational constraints are possible including:
  3467.        rotate about an axis, rotate about a point.
  3468.  
  3469.  
  3470.        6.20.2.6  _p_f_T_e_x_G_e_n
  3471.        A new PFSTATE attribute, pfTexGen encapsulates the GL's
  3472.        texgen() feature which automatically generates texture
  3473.        coordinates. The Wavefront OBJ file loader in libpfdb
  3474.        provides an example of the use of this new capability. Refer
  3475.        to that source code for usage examples.
  3476.  
  3477.  
  3478.        6.20.2.7  _p_f_T_r_a_n_s_p_a_r_e_n_c_y
  3479.        pfTransparency now supports PFTR_MS_ALPHA_MASK which enables
  3480.        multisample transparency but also writes the true alpha
  3481.        value into the frame buffer instead of fully opaque alpha
  3482.        values as PFTR_MS_ALPHA does.
  3483.  
  3484.  
  3485.        6.20.2.8  _p_f_D_e_c_a_l
  3486.        When using DISPLACE type decals, LAYERS are no longer
  3487.        required to be rendered immediately after their BASES - they
  3488.        can be drawn in any order. This introduces new LAYER-
  3489.        specific tokens:  PFDECAL_LAYER_FAST, PFDECAL_LAYER_DISPLACE
  3490.        and requires specific identification of all layers after the
  3491.  
  3492.  
  3493.  
  3494.  
  3495.  
  3496.  
  3497.  
  3498.  
  3499.  
  3500.  
  3501.  
  3502.                                   - 54 -
  3503.  
  3504.  
  3505.  
  3506.        first since each layer must be displaced slightly more than
  3507.        its predecessor.  The tokens PFDECAL_LAYER_1 ->
  3508.        PFDECAL_LAYER_7 are provided for layer identification.
  3509.  
  3510.  
  3511.        6.20.2.9  _p_f_C_y_c_l_e_B_u_f_f_e_r_/_p_f_C_y_c_l_e_M_e_m_o_r_y
  3512.  
  3513.        Note that pfCycleBuffer is obsolete with IRIS Performer2.2
  3514.        in favor of the pfFlux. IRIS Performer 2.0/2.1 pfCycleBuffer
  3515.        are still included in IRIS Performer 2.2.
  3516.  
  3517.        A new kind of pfMemory, pfCycleBuffer supports changing data
  3518.        in a pipelined, multiprocessing environment while
  3519.        maintaining data exclusion and frame-accurate behavior. A
  3520.        pfCycleBuffer manages a set of buffers called pfCycleMemorys
  3521.        and "rotates" them each frame, advancing the data
  3522.        modifications cleanly down the processing pipeline. libpf
  3523.        transparently handles the buffer rotations.
  3524.  
  3525.  
  3526.        6.20.2.10  _p_f_P_o_l_y_t_o_p_e
  3527.        A pfPolytope is a set of N half spaces whose intersection
  3528.        defines a possibly semi-infinite, convex volume which is
  3529.        useful for culling and intersection testing where a tighter
  3530.        bound than a pfSphere, pfBox, pfCylinder, pfFrustum is of
  3531.        benefit.
  3532.  
  3533.  
  3534.        6.20.2.11  _p_f_G_L_O_v_e_r_r_i_d_e
  3535.        Adds the ability to force the use of a particular GL
  3536.        mechanism to implement a libpr feature.
  3537.  
  3538.  
  3539.        6.20.2.12  _p_f_N_o_t_i_f_y
  3540.        pfNotify has been enhanced with new formatting and modes
  3541.        (PFNFY_MORE).  Refer to the pfNotify man page for full
  3542.        details.
  3543.  
  3544.  
  3545.        6.20.2.13  _p_f_G_e_t_T_i_m_e
  3546.        New functions. Refer to the reference pages for further
  3547.        information.
  3548.  
  3549.            ppppffffWWWWrrrraaaappppCCCClllloooocccckkkk
  3550.  
  3551.            ppppffffCCCClllloooocccckkkkNNNNaaaammmmeeee
  3552.  
  3553.            ppppffffCCCClllloooocccckkkkMMMMooooddddeeee
  3554.  
  3555.  
  3556.  
  3557.  
  3558.  
  3559.  
  3560.  
  3561.  
  3562.  
  3563.  
  3564.  
  3565.  
  3566.  
  3567.  
  3568.                                   - 55 -
  3569.  
  3570.  
  3571.  
  3572.        6.20.2.14  _W_i_n_d_o_w__S_y_s_t_e_m__R_o_u_t_i_n_e_s
  3573.        New window-system interface functions provide a single API
  3574.        for creating and managing windows that works across the IRIS
  3575.        GL, IRIS GLX Mixed Mode, and OpenGL-X environments.  Window
  3576.        system independent types have been provided to match the X
  3577.        Window System types to provide complete portability between
  3578.        the IRIS GL and OpenGL-X windowing environments.
  3579.  
  3580.  
  3581.        6.20.2.15  _p_f_Q_u_e_r_y_F_e_a_t_u_r_e_/_p_f_Q_u_e_r_y_S_y_s
  3582.        New QueryFeature routines determine the presence, absence,
  3583.        or limitations of features in the underlying graphics
  3584.        implementation, like the availability of attenuation in the
  3585.        lighting model or the availability of multiple graphics
  3586.        pipes.
  3587.  
  3588.        The QuerySys routines determine the capacity and limitations
  3589.        of the underlying graphics implementation, like the size of
  3590.        texture memory or the number of stencil planes available.
  3591.  
  3592.  
  3593.        6.20.2.16  _p_f_T_e_x_t_u_r_e__e_x_t_e_n_s_i_o_n_s
  3594.  
  3595.        6.20.2.17  _I_n_t_e_g_r_a_t_e_d__T_e_x_t__S_u_p_p_o_r_t
  3596.        Two and Three dimensional font rendering is supported by the
  3597.        new pfFont (libpr), pfString (libpr), and pfText (libpf)
  3598.        primitives.
  3599.  
  3600.        The pfFont facility provides the capability to load fonts
  3601.        for 3-D rendering with the string drawing routines from
  3602.        pfString and pfText.  IRIS Performer uses this facility to
  3603.        provide flat, extruded, and textured-quad fonts in three
  3604.        dimensions.
  3605.  
  3606.        pfString provides a pfGeoSet like facility for encapsulating
  3607.        geometry to display a string in 3-D with attributes such as
  3608.        color, arbitrary transformation matrix, and font (see
  3609.        pfFont).
  3610.  
  3611.        A pfText node is a list of pfStrings much as a pfGeode is a
  3612.        list of pfGeoSets. The two APIs are also similar - a new
  3613.        pfText node can be created and the list of pfStrings
  3614.        attached to it can be manipulated by addition, insertion,
  3615.        removal or replacement.
  3616.  
  3617.        The best examples of these new font tools at present are
  3618.        hello.c and helloC.C, both provided in the IRIS Performer
  3619.        source directory.
  3620.  
  3621.  
  3622.  
  3623.  
  3624.  
  3625.  
  3626.  
  3627.  
  3628.  
  3629.  
  3630.  
  3631.  
  3632.  
  3633.  
  3634.                                   - 56 -
  3635.  
  3636.  
  3637.  
  3638.        6.20.2.18  _p_f_Q_u_a_t
  3639.        A full set of quaternion utilities is defined in prmath.h
  3640.        and is documented in the pfQuat man page.
  3641.  
  3642.  
  3643.        6.20.3  _L_I_B_P_F__E_n_h_a_n_c_e_m_e_n_t_s
  3644.  
  3645.        6.20.3.1  _M_u_l_t_i_p_l_e__W_i_n_d_o_w_s__o_n__a__s_i_n_g_l_e__p_f_P_i_p_e
  3646.  
  3647.        Multiple windows can now be rendered from a single pfPipe.
  3648.        This allows a single drawing process to render to multiple
  3649.        windows on a single screen.  Libpf now requires use of the
  3650.        pfPipeWindow primitive for opening windows for pfPipes.  See
  3651.        the pfWindow and pfPipeWindow (pfConfigPWin()) reference
  3652.        pages for details.
  3653.  
  3654.  
  3655.        6.20.3.2  _p_f_M_o_r_p_h
  3656.  
  3657.        Note that pfMorph node is obsolete in 2.2.  We recommand
  3658.        using pfFlux/pfEngines instead of pfCycleBuffer and pfMorph
  3659.        feature.
  3660.  
  3661.        pfMorph is a new group node intended for automatic morphing
  3662.        of pfGeoSet attributes: colors, normals, coordinates, and
  3663.        texture coordinates but which can morph any floating point
  3664.        values. pfMorph is triggered during the new APP traversal
  3665.        and linearly combines N source arrays into a single
  3666.        destination which is typically a pfCycleBuffer used as a
  3667.        pfGeoSet attribute array.  By modifying the source weights
  3668.        each frame, the application can produce sophisticated,
  3669.        frame-accurate effects such as facial and skeletal animation
  3670.        and morphed, geometric level-of-detail.
  3671.  
  3672.  
  3673.        6.20.3.3  _p_f_D_B_a_s_e
  3674.        The DBASE process is a new addition to the IRIS Performer
  3675.        multiprocessing family. It is similar to the ISECT process
  3676.        in that it can run asynchronously with respect to the main
  3677.        processing pipeline (APP->CULL->DRAW). Callback and trigger
  3678.        functions, pfDBaseFunc() and pfDBase() respectively, allow
  3679.        explicit control and customization of the DBASE function.
  3680.        The DBASE is intended for asynchronous database processing,
  3681.        particularly paging to and from disk when using large
  3682.        databases. Note that IRIS Performer does not provide a
  3683.        paging facility directly - rather it provides the tools
  3684.        which the application can use to implement database paging.
  3685.        Database deletions are carried out in pfDBase() and do not
  3686.        slow down the synchronous pipeline if DBASE is configured as
  3687.        a separate process.
  3688.  
  3689.  
  3690.  
  3691.  
  3692.  
  3693.  
  3694.  
  3695.  
  3696.  
  3697.  
  3698.  
  3699.  
  3700.                                   - 57 -
  3701.  
  3702.  
  3703.  
  3704.        6.20.3.4  _p_f_B_u_f_f_e_r
  3705.        pfBuffer is the primary tool for asynchronous database
  3706.        manipulations. A pfBuffer isolates database changes to a
  3707.        given process, avoiding dangerous data collisions with other
  3708.        processes when multiprocessing.  Scene graphs built in an
  3709.        asynchronous process, such as the DBASE, do not affect the
  3710.        synchronous, real-time APP->CULL->DRAW pipeline and are
  3711.        quickly and safely merged into the main processing stream
  3712.        with pfMergeBuffer().
  3713.  
  3714.  
  3715.        6.20.3.5  _p_f_M_u_l_t_i_t_h_r_e_a_d
  3716.        pfMultithread adds a new multiprocessing dimension by
  3717.        multithreading a given IRIS Performer processing stage.
  3718.        Currently, only the CULL stage may be multithreaded such
  3719.        that thread culls a pfChannel. This is expected to be very
  3720.        useful for MCO applications where many pfChannels per pipe
  3721.        cause the CULL stage to become a bottleneck.
  3722.  
  3723.  
  3724.        6.20.3.6  _P_F_T_R_A_V___A_P_P
  3725.        PFTRAV_APP is a new automated IRIS Performer traversal
  3726.        intended for behavior computation, event distribution and
  3727.        other application level functions. It is carried out in the
  3728.        APP process and is initiated directly by pfAppFrame() or
  3729.        automatically by pfSync(). A wrapper callback and callback
  3730.        data (pfAppFunc(), pfPassAppData()) and node callbacks and
  3731.        data (pfNodeTravFuncs(), pfNodeTravData()) provide
  3732.        application extensibility similar to that offered for the
  3733.        CULL, DRAW, and ISECT traversals.
  3734.  
  3735.  
  3736.        6.20.3.7  _p_f_C_h_a_n_D_a_t_a
  3737.        pfChannel passthrough data may be supplied by the
  3738.        application with pfChanData() rather than allocated by the
  3739.        pfChannel with pfAllocChanData().  This allows pfChannels to
  3740.        share a single passthrough data block.
  3741.  
  3742.  
  3743.        6.20.3.8  _p_f_C_h_a_n_C_u_l_l_P_t_o_p_e
  3744.        pfChanCullPtope() specifies that a pfChannel use a
  3745.        pfPolytope, rather than its viewing pfFrustum, for culling.
  3746.        This allows highly customized culling for specific
  3747.        environments where visibility can be predetermined to some
  3748.        extent, e.g., when in a room and looking through a door the
  3749.        cull volume can be shrunk to the door opening.
  3750.  
  3751.  
  3752.        6.20.3.9  _p_f_C_h_a_n_N_o_d_e_I_s_e_c_t_S_e_g_s
  3753.        pfChanNodeIsectSegs() is identical to pfNodeIsectSegs() but
  3754.        includes a pfChannel to evaluate pfLODs during the
  3755.  
  3756.  
  3757.  
  3758.  
  3759.  
  3760.  
  3761.  
  3762.  
  3763.  
  3764.  
  3765.  
  3766.                                   - 58 -
  3767.  
  3768.  
  3769.  
  3770.        intersection traversal.  Thus, pfChanNodeIsectSegs()
  3771.        computes intersections with the same level-of-detail as is
  3772.        selected for rendering. This greatly simplifies operations
  3773.        such as terrain following on terrain which is modeled as
  3774.        levels-of-detail.
  3775.  
  3776.  
  3777.        6.20.3.10  _p_f_C_h_a_n_G_S_t_a_t_e_T_a_b_l_e
  3778.        pfChannels can provide a pfGeoState table which is accessed
  3779.        by indexed pfGeoSets. This simplifies the management of
  3780.        multiple views of a single database, such as infrared vs.
  3781.        out-the-window.
  3782.  
  3783.  
  3784.        6.20.3.11  _p_f_V_i_d_e_o_R_a_t_e
  3785.        In release 1.2, IRIS Performer internally computed the rate
  3786.        of the video clock.  In 2.0, IRIS Performer now queries the
  3787.        video microcode for the video retrace rate or accepts the
  3788.        rate set by the application with pfVideoRate().
  3789.  
  3790.  
  3791.        6.20.3.12  _p_f_C_o_n_f_i_g_S_t_a_g_e
  3792.        pfStageConfigFunc() allows the specification of an
  3793.        initialization callback for each IRIS Performer processing
  3794.        stage. pfConfigStage() invokes specified initialization
  3795.        callbacks in the appropriate processes at the next
  3796.        pfFrame(). Initialization callbacks typically establish the
  3797.        initial conditions of a process. Examples include setting
  3798.        non-degrading priorities and locking processes to CPUs for
  3799.        real-time applications and downloading textures in the DRAW
  3800.        stage.
  3801.  
  3802.  
  3803.        6.20.3.13  _p_f_L_o_o_k_u_p_N_o_d_e
  3804.        pfLookupNode() extends pfFindNode by searching for a path-
  3805.        named node of a particular type, beginning at a specific
  3806.        node. This greatly simplifies finding named parts of a
  3807.        pfCloned subgraph.
  3808.  
  3809.  
  3810.        6.20.3.14  _p_f_S_c_e_n_e_G_S_t_a_t_e
  3811.        pfScenes can now reference a pfGeoState that defines the
  3812.        "global state" which may be inherited by other pfGeoStates
  3813.        within the scene.
  3814.  
  3815.  
  3816.        6.20.3.15  _p_f_G_e_t_S_C_S_M_a_t_P_t_r__a_n_d__p_f_G_e_t_D_C_S_M_a_t_P_t_r
  3817.        pfGetDCSMatPtr() returns a pointer to the pfDCS matrix for
  3818.        fast access. Likewise, pfGetSCSMatPtr() returns a pointer to
  3819.        the pfSCS matrix.
  3820.  
  3821.  
  3822.  
  3823.  
  3824.  
  3825.  
  3826.  
  3827.  
  3828.  
  3829.  
  3830.  
  3831.  
  3832.                                   - 59 -
  3833.  
  3834.  
  3835.  
  3836.        6.20.3.16  _N_e_w__G_L_-_i_n_d_e_p_e_n_d_e_n_t__W_i_n_d_o_w_i_n_g__U_t_i_l_i_t_i_e_s
  3837.        IRIS Performer now provides utilities for opening, closing,
  3838.        and managing windows.  The same routines will manage pure
  3839.        IRIS GL windows, IRIS GL-X Mixed-Mode, and OpenGL-X windows.
  3840.        Libpf application will now use the new pfPipeWindow for
  3841.        opening IRIS Performer windows.  See the pfWindow (libpr)
  3842.        and pfPipeWindow (libpf) (pfConfigPWin()) reference pages
  3843.        for details.
  3844.  
  3845.  
  3846.        6.20.3.17  _A_P_I__C_h_a_n_g_e_s
  3847.        pfSelectCtab() is now pfApplyCtab()
  3848.        pfGetMallcoSize() is now pfGetSize()
  3849.        pfGetHyperId() is now pfGetPipeHyperId()
  3850.  
  3851.  
  3852.        6.20.3.18  _R_e_f_e_r_e_n_c_e__C_o_u_n_t_i_n_g
  3853.        All pfObjects, including pfNodes now have a reference count.
  3854.        A pfGroup increments the reference count of all its
  3855.        children.
  3856.  
  3857.  
  3858.        6.20.3.19  _M_o_d_e__Q_u_e_r_y__S_e_m_a_n_t_i_c_s
  3859.        pfGetGStateAttr/Mode do not return the global values of
  3860.        inherited state elements. Instead NULL and -1 are returned.
  3861.        Use pfGetCurGStateAttr/Mode for 1.2 behavior.
  3862.  
  3863.  
  3864.        6.20.3.20  _V_i_d_e_o__C_l_o_c_k
  3865.        pfInitVClock() no longer starts and stops the video clock.
  3866.        Instead, use pfStart/StopVClock() to start and stop video
  3867.        interrupts. pfStart/StopVClock are only necessary for
  3868.        VGX/VGXT graphics and are ignored on other graphics.
  3869.  
  3870.  
  3871.        6.20.3.21  _p_f_P_i_p_e_S_c_r_e_e_n
  3872.        Proper multipipe operation now requires that pipes be
  3873.        assigned a screen (pfPipeScreen) before the first pfFrame().
  3874.        Otherwise, pipes will be automatically assigned a screen.
  3875.  
  3876.  
  3877.        6.20.3.22  _p_f_E_v_a_l_u_a_t_e_L_O_D
  3878.        pfEvaluateLOD() returns a floating point number indicating
  3879.        which child is selected by a given pfChannel. The fractional
  3880.        portion of the number is used for fading transitions.
  3881.  
  3882.  
  3883.        6.20.3.23  _p_f_L_O_D_S_t_a_t_e
  3884.        pfLODStates are used to specify how individual LOD's or
  3885.        groups of LODs will respond to stress and range.
  3886.        pfLODStates can either be explicitly set per LOD or set as
  3887.  
  3888.  
  3889.  
  3890.  
  3891.  
  3892.  
  3893.  
  3894.  
  3895.  
  3896.  
  3897.  
  3898.                                   - 60 -
  3899.  
  3900.  
  3901.  
  3902.        an index into a list of pfLODStates provided to a pfChannel.
  3903.        Thus pfLODStates can make the same pfLOD behave differently
  3904.        in different channels as well as differently under different
  3905.        stress conditions.  pfLODStates ultimately modify the range
  3906.        and fade transition calculations made by performer when
  3907.        culling.  See pfLODState, pfLOD, and pfChannel.
  3908.  
  3909.  
  3910.        6.20.3.24  _p_f_L_O_D__e_n_h_a_n_c_e_m_e_n_t_s
  3911.        pfLODs now support per-pair transition zones for fade LOD
  3912.        See the pfLODTransition reference page.
  3913.  
  3914.        pfLODs now respond to stress by scaling LOD ranges and
  3915.        transition zones and take a pfLODState structure to describe
  3916.        the desired stress behavior of a pfLOD. See the pfLODState
  3917.        reference page.
  3918.  
  3919.        LOD Priority Classes can be formed by the sharing of
  3920.        pfLODState structures across a set of LODs.
  3921.  
  3922.        Per-Channel LOD Priority Classes can be formed by assigning
  3923.        pfChannels with tables of pfLODStates and assigning pfLODs
  3924.        an index into these tables. See the pfChanLODAttr and
  3925.        pfLODLODStateIndex reference pages.
  3926.  
  3927.  
  3928.  
  3929.        6.20.4  _l_i_b_p_f_d_u__E_n_h_a_n_c_e_m_e_n_t_s
  3930.  
  3931.        6.20.4.1  _O_p_t_i_m_i_z_i_n_g__S_c_e_n_e__B_u_i_l_d_e_r__f_o_r__u_s_e__i_n__F_i_l_e__L_o_a_d_e_r_s
  3932.        Performer 2.0 contains a new layer of support for easily
  3933.        converting databases from external formats into performer
  3934.        runtime structures.  This new layer is called libpfdu which
  3935.        stands for library of performer database utilities.  The
  3936.        pfdBuilder contains mechanisms for completely converting
  3937.        external database formats and data into efficient IRIS
  3938.        performer structures.  The builder will take care of state
  3939.        sharing and sort your geometry by state.  Collections of
  3940.        graphics state and geometry are given to the pfdBuilder as a
  3941.        database is read in. At the end of reading a database file,
  3942.        a pfNode containing an efficient Performer representation of
  3943.        the database can be obtained.  This new API supersedes the
  3944.        previous pfuBuilder which was a simple interface for
  3945.        encapsulating geometric data into performer structures in an
  3946.        intuitive way.  This new layer of support is built on top of
  3947.        and is a superset of the previous pfuBuilder (which has now
  3948.        become the pfdGeoBuilder) that was released with Performer
  3949.        1.2.  Check out
  3950.  
  3951.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffffdddduuuu....hhhh
  3952.  
  3953.  
  3954.  
  3955.  
  3956.  
  3957.  
  3958.  
  3959.  
  3960.  
  3961.  
  3962.  
  3963.  
  3964.                                   - 61 -
  3965.  
  3966.  
  3967.  
  3968.        for mode settings and api for the new extended builder.
  3969.  
  3970.        libpfdu is the Performer library of database utilities.  Its
  3971.        purpose is to provide helpful functions for constructing
  3972.        optimized Performer data structures and scene graphs.  It is
  3973.        used mainly by database loaders which take an external file
  3974.        format containing 3d geometry and graphics state and load
  3975.        them into Performer optimized run-time only structures.
  3976.        Note that these utilities often prove very useful as most
  3977.        modeling tools and file formats represent their data in
  3978.        structures that correspond to the way users model data and
  3979.        these data structures are often necessarily mutually
  3980.        exclusive with effective and efficient Performer run-time
  3981.        structures.  libpfdu contains many utilities including dso
  3982.        support for database loaders and their modes, file path
  3983.        support, etc, but the heart of libpfdu is the notion of the
  3984.        Performer database 'builder' - pfdBuilder.
  3985.  
  3986.        The builder is a tool to allow users to input/output a
  3987.        collection of geometry and graphics state in immediate mode
  3988.        fashion (similar to Open/Iris GL).  Data is inputed to the
  3989.        builder one geometric primitive at a time along with its
  3990.        corresponding graphics state.  When all of the data has been
  3991.        inputed, the user simply requests optimized Performer data
  3992.        structures which can then be used as a part of a Performer
  3993.        Scene Graph.  The builder hashs geometry into different
  3994.        'bins' based on the geometry's attribute binding types and
  3995.        associated graphics state.  It also keeps track of graphics
  3996.        state elements (textures,materials,light models, fog,etc)
  3997.        and shares state elements whenever possible.  In the end,
  3998.        the builder will create Performer 'pfGeoSets' that contain
  3999.        triangle meshes created by running the original geometry
  4000.        through the libpfdu tmeshing utility.  To go along with each
  4001.        pfGeoSet, the builder builds up a Performer pfGeoState
  4002.        (Performer's encapsulated state primitive) which has been
  4003.        optimized to share as many attributes as possible with other
  4004.        pfGeoStates being build (and possibly even with a more
  4005.        global pfChannelGState).  Having created all of these
  4006.        Performer primitives (pfGeoSets and pfGeoStates) the builder
  4007.        will place them in a Performer leaf node (pfGeode), and
  4008.        possibly even artificially create a spatial hierarchy by
  4009.        running the new database through a spatial breakup utility
  4010.        function which is also contained in libpfdu.  Note that this
  4011.        builder should also allow the user to extend the notion of a
  4012.        'graphics state' by registering callback functionality
  4013.        through builder api and then treating this
  4014.        state/functionality like any other Performer state/mode
  4015.        (although such uses of the builder are of course at least
  4016.        slightly more complicated).
  4017.  
  4018.        In short libpfdu is a collection of utilities that
  4019.  
  4020.  
  4021.  
  4022.  
  4023.  
  4024.  
  4025.  
  4026.  
  4027.  
  4028.  
  4029.  
  4030.                                   - 62 -
  4031.  
  4032.  
  4033.  
  4034.        effectively act as a data funnel where users input flattened
  4035.        3d graphics information and are given in return fully
  4036.        functional and hopefully well optimized Performer run-time
  4037.        structures.
  4038.  
  4039.  
  4040.  
  4041.        6.20.5  _l_i_b_p_f_d_b__E_n_h_a_n_c_e_m_e_n_t_s
  4042.  
  4043.        6.20.5.1  _N_e_w__F_i_l_e__F_o_r_m_a_t_s   OpenInventor 2.0 file support.
  4044.        This is a completely new loader that uses OpenInventor
  4045.        traversal of the input scene graph to create the Performer
  4046.        scene graph, allowing robust conversion of all geometry.
  4047.  
  4048.        AutoDesk 3DStudio file support using the 3dsftk.
  4049.  
  4050.        Side Effects Software Prisms (.poly and .bpoly) file
  4051.        support.
  4052.  
  4053.        Medit Productions Medit (.medit) file support
  4054.  
  4055.        S1000 file support, based on code from Texas Instruments.
  4056.  
  4057.        Several other formats. Look in libpfdb for the complete
  4058.        list.
  4059.  
  4060.  
  4061.        6.20.6  _S_t_r_u_c_t_u_r_a_l__C_h_a_n_g_e_s
  4062.  
  4063.        6.20.6.1  _C_l_a_s_s__s_t_r_u_c_t_u_r_e
  4064.        One of the major differences from 1.2 is that libpr is now
  4065.        written in C++ and the class tree has changed. 1.2 had both
  4066.        a prObject and pfObject - now there is a single pfObject
  4067.        which is derived from IRIS Performer's base class, pfMemory.
  4068.        There are no more pr-prefixed routines which were used for
  4069.        libpr->libpf inheritance, e.g, pfLight -> pfLightSource.
  4070.  
  4071.  
  4072.        6.20.6.2  _p_f_T_y_p_e
  4073.        IRIS Performer has changed its type system to support new,
  4074.        application-derived types. pfGetType() now returns a pfType*
  4075.        instead of a bitmask. Each IRIS Performer data type which
  4076.        has an explicit allocator (usually pfNew*()) has an
  4077.        associated pfType which is created at initialization time by
  4078.        pfInit().  The pfType corresponding to a particular class is
  4079.        returned by pfGet<*>ClassType(), e.g.,
  4080.        pfGetGroupClassType().
  4081.  
  4082.        The primary difference in 2.0 is the fact that types are no
  4083.        longer represented with bitmasks where the inheritance chain
  4084.        of a particular type is encoded in the bitmask, e.g.,
  4085.  
  4086.  
  4087.  
  4088.  
  4089.  
  4090.  
  4091.  
  4092.  
  4093.  
  4094.  
  4095.  
  4096.                                   - 63 -
  4097.  
  4098.  
  4099.  
  4100.        PFTYPE_SCS == (100 | PFCLASS_SCS | PFCLASS_GROUP |
  4101.        PFCLASS_NODE), indicating that SCS is derived from pfGroup
  4102.        and pfNode.  pfType is an opaque data structure whose
  4103.        inheritance chain must be queried through pfIsOfType().
  4104.  
  4105.        Here are the old and new methods for testing an object for
  4106.        exact type equality. The 1.2 method:
  4107.  
  4108.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== PPPPFFFFTTTTYYYYPPPPEEEE____SSSSCCCCSSSS))))
  4109.  
  4110.        and the 2.0 methods, which are equivalent
  4111.  
  4112.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))
  4113.  
  4114.            iiiiffff ((((ppppffffIIIIssssEEEExxxxaaaaccccttttTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))
  4115.  
  4116.        Here are the old and new methods for testing an object for
  4117.        derivation from a give type. The 1.2 method:
  4118.  
  4119.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) &&&& PPPPFFFFCCCCLLLLAAAASSSSSSSS____GGGGRRRROOOOUUUUPPPP))))
  4120.  
  4121.        and the 2.0 method
  4122.  
  4123.            iiiiffff ((((ppppffffIIIIssssOOOOffffTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttGGGGrrrroooouuuuppppCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))
  4124.  
  4125.        Special care should be taken when porting to the new type
  4126.        API.
  4127.  
  4128.  
  4129.        6.20.7  _C_h_a_n_g_e_s__i_n__l_i_b_p_r
  4130.  
  4131.        6.20.7.1  _D_e_f_a_u_l_t__E_n_a_b_l_e_s
  4132.        PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
  4133.        by default.  Databases created with loaders that assumed
  4134.        specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
  4135.        be rendered improperly. All IRIS Performer loaders shipped
  4136.        with 2.0 create pfGeoStates that assume the global default
  4137.        is the same as that set by pfBasicState(), i.e., everything
  4138.        is OFF.
  4139.  
  4140.  
  4141.        6.20.7.2  _L_i_n_e__W_i_d_t_h__a_n_d__P_o_i_n_t__S_i_z_e
  4142.        pfGeoSets with linewidth/pointsize of <= 0 will not set
  4143.        linewidth or pointsize but will inherit it through the GL.
  4144.  
  4145.  
  4146.        6.20.7.3  _A_l_p_h_a__R_e_f_e_r_e_n_c_e__V_a_l_u_e
  4147.        The PFSTATE_ALPHAREF state element has changed from an
  4148.        integer in the range 0-255 to a float in the range 0-1 and
  4149.        is now set on pfGeoStates with the new routine, pfGStateVal.
  4150.        A warning will be generated if set through pfGStateMode.
  4151.  
  4152.  
  4153.  
  4154.  
  4155.  
  4156.  
  4157.  
  4158.  
  4159.  
  4160.  
  4161.  
  4162.                                   - 64 -
  4163.  
  4164.  
  4165.  
  4166.        6.20.7.4  _D_e_c_a_l__I_m_p_l_e_m_e_n_t_a_t_i_o_n
  4167.        pfDecal no longer sets zwritemask to 0 when drawing
  4168.        displaced layers.  This allows layers to be drawn separately
  4169.        from their bases, enabling improved sorting by graphics
  4170.        mode.
  4171.  
  4172.  
  4173.        6.20.7.5  _M_a_t_h__F_u_n_c_t_i_o_n_s
  4174.        pfXformPt3/Vec3 previously considered the last column of the
  4175.        matrix and divided by the homogeneous coordinate, w. The new
  4176.        pfXformPt3/Vec3 are much faster and treats the pfMatrix as a
  4177.        4x3 matrix.  The old behavior is now accessed through the
  4178.        new pfFullXformPt3/Vec3 routines.
  4179.  
  4180.        pfInvertMat is now named pfInvertFullMat but a #define
  4181.        ensures 1.2 compatibility.
  4182.  
  4183.        pfMakeRotOntoMat is obsoleted in favor of the much faster
  4184.        pfMakeVecRotVecMat which assumes normalized input vectors.
  4185.  
  4186.  
  4187.        6.20.7.6  _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
  4188.        pfFrustAspect is no longer persistent. In 1.2, automatic
  4189.        frustum calculation (e.g. PFFRUST_CALC_HORIZ) was always in
  4190.        effect once set. In 2.0, pfFrustAspect recomputes the
  4191.        frustum only at time of invocation.
  4192.  
  4193.  
  4194.        6.20.8  _C_h_a_n_g_e_s__i_n__l_i_b_p_f
  4195.  
  4196.        6.20.8.1  _D_e_f_a_u_l_t__E_n_a_b_l_e_s
  4197.        PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
  4198.        by default.  Databases created with loaders that assumed
  4199.        specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
  4200.        be rendered improperly. All IRIS Performer loaders shipped
  4201.        with 2.0 create pfGeoStates which assume the global default
  4202.        is the same as that set by pfBasicState(), i.e., everything
  4203.        is OFF. To achieve 1.2 behavior with 1.2 loaders, call the
  4204.        following in the DRAW process after the window is opened:
  4205.  
  4206.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____LLLLIIIIGGGGHHHHTTTTIIIINNNNGGGG))));;;;
  4207.  
  4208.            ////**** OOOOnnnnllllyyyy oooonnnn IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy////RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee////IIIImmmmppppaaaacccctttt////VVVVGGGGXXXXTTTT////VVVVGGGGXXXX ****////
  4209.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____TTTTEEEEXXXXTTTTUUUURRRREEEE))));;;;
  4210.  
  4211.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____FFFFOOOOGGGG))));;;;
  4212.  
  4213.        6.20.8.2  _M_u_l_t_i_-_c_h_a_n_n_e_l__f_o_g__a_n_d__l_i_g_h_t_i_n_g__c_o_n_s_i_s_t_e_n_c_y
  4214.        pfChannels now encode rotational offsets (pfChanViewOffsets)
  4215.        in the ModelView instead of the Projection matrix.
  4216.        Consequently, fog always matches across adjacent pfChannels
  4217.  
  4218.  
  4219.  
  4220.  
  4221.  
  4222.  
  4223.  
  4224.  
  4225.  
  4226.  
  4227.  
  4228.                                   - 65 -
  4229.  
  4230.  
  4231.  
  4232.        but for proper lighting, a local viewer lighting model is
  4233.        required (pfLModelLocal).
  4234.  
  4235.  
  4236.        6.20.8.3  _T_y_p_e__i_n_h_e_r_i_t_a_n_c_e
  4237.        Multiple inheritance through the C API is gone. Previously,
  4238.        pfChannels could use pfFrustum API, e.g.,
  4239.        pfMakePerspFrust(chan,...) pfFrameStats could use pfStats
  4240.        API, and pfLightSources could use pfLight API, e.g.,
  4241.        pfLightPos(lsource...). Additional routines are now provided
  4242.        to maintain the same functionality without the complexities
  4243.        of multiple inheritance. The new routines name are simply
  4244.        the old routines where the "base" class name is replaced
  4245.        with the "derived" class name. For example, pfMakePerspFrust
  4246.        becomes pfMakePerspChan and pfLightPos becomes pfLSourcePos.
  4247.        Comprehensive tables illustrating the correspondence between
  4248.        routine names are found in pfChannel, pfFrameStats, and
  4249.        pfLightSource man pages.
  4250.  
  4251.  
  4252.        6.20.8.4  _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
  4253.        Customizing a viewing frustum with pfMakePerspChan or
  4254.        pfMakeOrthoChan now disables the automatic viewport aspect
  4255.        ratio matching feature of pfChannel (pfChanAutoAspect).
  4256.  
  4257.  
  4258.        6.20.8.5  _A_P_I__C_h_a_n_g_e_s
  4259.        pfChanCullFunc and pfChanDrawFunc are now subsumed by
  4260.        pfChanTravFunc.
  4261.  
  4262.        pfStageConfigFunc() and pfConfigStage() replace the now
  4263.        obsolete pfInitPipe().
  4264.  
  4265.  
  4266.        6.20.8.6  _B_u_g__f_i_x
  4267.        PFPHASE_FLOAT and PFPHASE_LOCK now work in single process
  4268.        mode.
  4269.  
  4270.  
  4271.        6.20.8.7  _p_f_S_w_i_t_c_h__s_e_m_a_n_t_i_c_s
  4272.        pfSwitchVal() used to determine the validity of the switch
  4273.        value which was problematic if no children had been added to
  4274.        the pfSwitch yet. The validity check is now deferred to
  4275.        individual traversal routines.
  4276.  
  4277.  
  4278.        6.20.8.8  _p_f_D_a_t_a_P_o_o_l_s
  4279.        When Performer shared memory has been created, pfDataPools
  4280.        are now positioned in the virtual address space so that
  4281.        conflicts are less likely to arise.  Such conflicts were a
  4282.        frequent cause of failures of pfAttachDPool.  Deleting a
  4283.  
  4284.  
  4285.  
  4286.  
  4287.  
  4288.  
  4289.  
  4290.  
  4291.  
  4292.  
  4293.  
  4294.                                   - 66 -
  4295.  
  4296.  
  4297.  
  4298.        data pool now detaches it from the address space.
  4299.  
  4300.  
  4301.        6.20.8.9  _p_f_P_a_r_t_i_t_i_o_n_s
  4302.        Allow better specification of the spacing and positioning of
  4303.        the spatial partition to reduce construction time. They also
  4304.        work now.
  4305.  
  4306.  
  4307.        6.20.8.10  _O_t_h_e_r__C_h_a_n_g_e_s
  4308.  
  4309.  
  4310.        6.20.8.11  _E_l_i_m_i_n_a_t_i_o_n__o_f__m_u_l_t_i_p_l_e__i_n_h_e_r_i_t_a_n_c_e
  4311.        The CAPI inheritance of pfChannel from pfFrustum,
  4312.        pfLightSource from pfLight and pfFrameStats from pfStats has
  4313.        been removed.  API has been added on the formerly derived to
  4314.        duplicate the functionality of the former base class, e.g.
  4315.        pfApplyFrust(chan) -> pfApplyChan(chan).
  4316.  
  4317.  
  4318.        6.20.8.12  _L_i_g_h_t__M_o_d_e_l__A_t_t_e_n_u_a_t_i_o_n__v_s__L_i_g_h_t__A_t_t_e_n_u_a_t_i_o_n
  4319.        IRIS GL: Light Attenuation is on the pfLightModel
  4320.  
  4321.            vvvvooooiiiidddd ppppffffLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
  4322.                ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;
  4323.  
  4324.            vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
  4325.                ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;
  4326.  
  4327.        OpenGL: Light Attenuation is on the pfLight
  4328.  
  4329.            vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
  4330.                ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;
  4331.  
  4332.            vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
  4333.                ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;
  4334.  
  4335.        6.20.8.13  _p_f_A_l_p_h_a_F_u_n_c__n_o_w__t_a_k_e_s__a__f_l_o_a_t__f_o_r__r_e_f
  4336.  
  4337.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;
  4338.  
  4339.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;
  4340.  
  4341.        6.20.8.14  _p_f_G_e_t_A_l_p_h_a_F_u_n_c__n_o_w__r_e_t_u_r_n_s__a__f_l_o_a_t__f_o_r__r_e_f
  4342.  
  4343.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;
  4344.  
  4345.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;
  4346.  
  4347.  
  4348.  
  4349.  
  4350.  
  4351.  
  4352.  
  4353.  
  4354.  
  4355.  
  4356.  
  4357.  
  4358.  
  4359.  
  4360.                                   - 67 -
  4361.  
  4362.  
  4363.  
  4364.        6.20.8.15  _p_f_G_S_t_a_t_e_M_o_d_e__a_n_d__p_f_G_e_t_G_S_t_a_t_e_M_o_d_e
  4365.        pf{Get}GStateMode can no longer accept the PFSTATE_ALPHAREF
  4366.        token.  Use
  4367.  
  4368.            ppppffffGGGGSSSSttttaaaatttteeeeVVVVaaaallll((((ggggssssttttaaaatttteeee,,,, PPPPFFFFSSSSTTTTAAAATTTTEEEE____AAAALLLLPPPPHHHHAAAARRRREEEEFFFF,,,, vvvvaaaallll))));;;;
  4369.  
  4370.        6.20.8.16  _p_f_L_i_g_h_t_C_o_l_o_r__a_n_d__p_f_G_e_t_L_i_g_h_t_C_o_l_o_r
  4371.        pfLightColor and pfGetLightColor now take arguments to
  4372.        specify which color.
  4373.  
  4374.            wwwwaaaassss:::: ppppffffLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaannnndddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaarrrreeee oooobbbbssssoooolllleeeetttteeee....
  4375.  
  4376.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
  4377.                    ffffllllooooaaaatttt rrrr,,,, ffffllllooooaaaatttt gggg,,,, ffffllllooooaaaatttt bbbb))));;;;
  4378.  
  4379.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
  4380.                    ffffllllooooaaaatttt**** rrrr,,,, ffffllllooooaaaatttt**** gggg,,,, ffffllllooooaaaatttt**** bbbb))));;;;
  4381.  
  4382.        6.20.8.17  _p_f_I_n_i_t_G_f_x
  4383.        pfInitGfx() has changed API, location and behavior:
  4384.  
  4385.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffIIIInnnniiiittttGGGGffffxxxx((((ppppffffPPPPiiiippppeeee ****pppp))));;;;
  4386.  
  4387.            nnnneeeewwww:::: ppppffffIIIInnnniiiittttGGGGffffxxxx((((vvvvooooiiiidddd))));;;;
  4388.  
  4389.        pfInitGfx() should now be used to initialize all pfWindows
  4390.        and pfPipeWindows.
  4391.  
  4392.  
  4393.        6.20.8.18  _p_f_I_n_i_t_G_L_X_G_f_x
  4394.        pfInitGLXGfx(pfPipe *) has been removed. Use the
  4395.        pfPipeWindow utilities.
  4396.  
  4397.  
  4398.        6.20.8.19  _p_f_G_e_t_P_i_p_e_W_i_n__a_n_d__p_f_G_e_t_P_i_p_e_G_L_X_W_i_n_s
  4399.        pfGetPipeWin and pfGetPipeGLXWins have been removed. There
  4400.        is now pfGetPipePWin() to support this functionality.
  4401.  
  4402.  
  4403.        6.20.8.20  _p_f_I_n_i_t_P_i_p_e
  4404.        pfInitPipe() is obsoleted in favor of pfStageConfigFunc()
  4405.        and pfConfigStage().  pfInitPipe() no longer is used to
  4406.        create windows.  Use pfConfigPWin for a window
  4407.        initialization callback.  Use pfConfigStage for initializing
  4408.        (or later re-configuring) the CULL or DRAW processes
  4409.        (stages) for a given pipe.
  4410.  
  4411.  
  4412.        6.20.8.21  _p_f_G_e_t_P_i_p_e_O_r_i_g_i_n
  4413.        pfGetPipeOrigin() has been removed.  Use pfGetWinOrigin() or
  4414.        pfGetPWinOrigin() to get the size of a pfWindow or
  4415.  
  4416.  
  4417.  
  4418.  
  4419.  
  4420.  
  4421.  
  4422.  
  4423.  
  4424.  
  4425.  
  4426.                                   - 68 -
  4427.  
  4428.  
  4429.  
  4430.        pfPipeWindow respectively.
  4431.  
  4432.  
  4433.        6.20.8.22  _p_f_G_e_t_P_i_p_e_S_i_z_e
  4434.        pfGetPipeSize() now returns the screen size of a pfPipe. Use
  4435.        pfGetWinSize() or pfGetPWinSize() to get the size of a
  4436.        pfWindow or pfPipeWindow respectively.
  4437.  
  4438.  
  4439.        6.20.8.23  _p_f_u_W_i_d_g_e_t_F_u_n_c__r_e_n_a_m_e_d
  4440.        pfuWidgetFunc() is now pfuWidgetActionFunc().
  4441.  
  4442.  
  4443.        6.20.8.24  _p_f_u_E_n_a_b_l_e_P_a_n_e_l
  4444.        pfuEnablePanel() no longer takes an enable argument.
  4445.        Instead, pfuPanels are enabled/disabled with
  4446.        pfuEnablePanel() and pfuDisablePanel() respectively.
  4447.  
  4448.  
  4449.        6.20.8.25  _p_f_u_G_e_t_P_a_n_e_l_S_i_z_e
  4450.        pfuGetPanelSize now follows standard convention of (xo, yo,
  4451.        xs, ys) parameter ordering.
  4452.  
  4453.            wwwwaaaassss:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
  4454.                     iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****yyyyssss))));;;;
  4455.  
  4456.            nnnneeeewwww:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllOOOOrrrrggggSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
  4457.                     iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyssss))));;;;
  4458.  
  4459.        6.20.8.26  _p_f_I_n_i_t_P_W_i_n
  4460.        pfInitPWin is now pfConfigPWin
  4461.  
  4462.  
  4463.  
  4464.  
  4465.  
  4466.  
  4467.  
  4468.  
  4469.  
  4470.  
  4471.  
  4472.  
  4473.  
  4474.  
  4475.  
  4476.  
  4477.  
  4478.  
  4479.  
  4480.  
  4481.  
  4482.  
  4483.  
  4484.  
  4485.  
  4486.  
  4487.  
  4488.  
  4489.